Nipaa's Blog

🎮 How to Properly Prepare Graphics for Web Games and Applications

An engineering approach to preparing graphics for fast, scalable web games and modern web applications.

Overview

When a beginner developer creates a web game or an interface, they usually think only about making the image look beautiful. This is an understandable mistake. The user sees graphics, so it feels like appearance is the most important thing.

But the real performance of a web application depends on much more than beauty.

Poorly prepared graphics can cause:

Good graphics architecture is not just “compressing images”. It is an engineering approach.

Let's go through the main principles.

1. Vector and Raster Graphics Are Different Tools

The first thing to understand is simple: not all graphics are the same.

Raster graphics are made of pixels.

Examples of raster formats:

If you enlarge a raster image too much, it loses quality.

Example:

You have an icon with a size of 32×32 pixels.

If you stretch it to 300×300, the result will be blurry and ugly.

Raster graphics work well for:

Now let's look at vector graphics.

A vector image is not a set of pixels. It is a mathematical description of lines, curves, and shapes.

A typical example:

SVG

The advantage:

A vector image can be scaled almost infinitely without losing quality.

Vector graphics are excellent for:

A very common mistake:

“SVG is always better because it scales.”

This is wrong.

SVG is not magic.

If an SVG contains a complex scene with many paths, curves, and effects, the browser has to calculate and render all that geometry.

This can be much more expensive than simply displaying a ready image.

So the rule is simple:

The correct question is not “what is more modern?”, but “what is cheaper to render?”.

2. If the Browser Can Build It Itself — Do Not Send an Image

This is one of the most underestimated principles.

Before creating a graphic file, ask yourself:

Do I really need an image here?

A modern browser can do a lot by itself.

It can efficiently build:

Bad solutions:

Why is this bad?

Because an image requires:

Browser built-in capabilities already exist for free.

Example.

Bad:

using PNG for a button with a background and rounded corners.

Correct:

using CSS:

Example with text.

A very bad practice:

making text as an image.

Why?

But there is an important nuance.

Do not turn this rule into a religion.

Sometimes browser rendering can be more expensive.

For example, when a decorative block is built using:

In that case, a ready optimized bitmap can be faster.

The main principle:

do not send over the network what the browser can efficiently build itself.

3. Choose the Right Format

There is no universal best format.

Each format solves its own task.

PNG

Use it when you need:

Disadvantage:

PNG is often very heavy.

WebP

In practice, this is one of the best universal choices for most web projects.

Advantages:

Good for:

AVIF

AVIF provides even stronger compression.

But there are disadvantages:

Sometimes a small file loads quickly but decodes slowly.

JPEG

Use JPEG only for:

Do not use JPEG for:

4. Do Not Store Images Larger Than Needed

This is one of the most common mistakes.

You have a button that is displayed as 64×64.

But the designer exported it as 2048×2048.

What happens?

The browser:

This is an absolutely meaningless waste of resources.

The correct approach:

the file size should be close to the real display size.

Bad:

1024×1024 → displayed as 48×48

Good:

64×64 → displayed as 64×64

5. Consider HiDPI / Retina

Modern displays have high pixel density.

So an image that looks normal on an old monitor can look blurry on a modern device.

A typical approach:

Example:

icon.webp
icon@2x.webp

But this does not mean that you should blindly double everything.

Look at real usage.

6. Crop Empty Space

Transparent space is still data.

Mistake:

a character occupies 100×100, but is exported as 1000×1000 with transparent borders.

Problems:

A transparent pixel is not free.

7. Combine Small Assets

A very common mistake:

storing dozens of small files.

For example:

Why is this bad?

Because every file is a separate request.

Even if the file is small.

Every request includes:

100 files of 5 KB can be worse than one 500 KB file.

Useful solutions:

8. Polling Kills Server Performance

This is a very important architectural point.

Suppose the client makes:

GET /check_status

every 2 seconds.

If you have 1000 players:

500 requests per second

If each client separately asks for:

you already get thousands of requests.

Even if the responses are small, every request starts:

This is expensive.

Bad:

Better:

/game_sync

Even better:

API architecture affects performance no less than graphics.

9. Runtime Memory Is More Important Than File Size

This is a very important point that beginners often do not understand.

File:

100 KB WebP

After decoding:

it can occupy megabytes of memory.

Why?

The GPU does not work with a compressed file.

The GPU works with raw texture data.

Downloaded file size and real memory consumption are different things.

10. Lossy and Lossless

Lossless:

Lossy:

For many game assets, the visual difference is almost invisible.

You should not fanatically use lossless everywhere.

11. Do Not Force the Browser to Constantly Scale Images

If an image is constantly being scaled:

This is especially critical for:

12. Preload Important Assets

Bad scenario:

the player triggers an explosion effect for the first time.

And only at that moment the file starts loading.

Result:

freeze

Correct:

preload before the match starts.

13. Use Caching

Without caching, the browser will repeatedly load the same resources.

Use:

Example:

piece.8f3c1.webp

14. Power-of-Two Textures

Classic sizes:

Today this is not always required.

But sometimes it is useful for:

15. Separate Source Files and Production Assets

Do not send users:

Pipeline:

source → export → optimize → deploy

16. Animation Also Costs Resources

Frame-by-frame animation:

more expensive.

Transform animation:

usually cheaper.

For example:

These are often better than constantly changing a bitmap.

17. Measure, Do Not Guess

Not:

“I think it is faster.”

Check it.

Tools:

18. Final Thoughts: Graphics Optimization Is Architecture, Not Just Images

The main beginner mistake:

thinking that graphics optimization simply means reducing image size.

In reality, the correct process starts much earlier.

You need to ask the right questions:

A fast web game is not a set of beautiful pictures.

It is competent system engineering.

Back to Coding