Short answer: yes, and they matter more than most people assume. A browser downloads the file at its stored size no matter how small the space it is drawn into, so a 4000-pixel photo shown in a 400-pixel card costs the visitor ten times the pixels they will ever see. Resize before you upload, and check the two numbers the article below points at.
Compression gets all the attention when people talk about image weight. On most sites the bigger problem is simpler and less discussed: the images are drawn into a space far smaller than the file that carries them.
The waste that nobody looks at
A phone photo is around 4000 pixels wide. Drop it into a page as a card thumbnail and the browser draws it into perhaps 400 pixels. Every one of the other 3600 columns of pixels was downloaded, decoded, held in memory, and then thrown away by the downscaling step.
The numbers are worse than they sound, because pixel count scales with the square. A 4000 × 3000 image is 12 million pixels. A 400 × 300 image is 120 thousand. The second is 1% of the first. The file sizes differ by roughly that ratio too.
So a page showing eight product thumbnails might be shipping 12 MB of image data to display eight images totalling 120 thousand pixels each. The visitor pays for all of it in download time, parse time, and memory.
Why "the browser will scale it" is not a defence
It is true that the browser will scale it down. It is also true that this happens after the whole file has crossed the network, which is the expensive part. And the scaling the browser performs under time pressure is not the careful resampling a dedicated tool would do — it is a fast approximation, which is one reason oversized images sometimes look slightly soft on screen.
There is a second cost that rarely gets mentioned: memory. A decoded image occupies width × height × 4 bytes in memory, regardless of how well the file was compressed on disk. A 4000 × 3000 photo takes about 48 MB once decoded. On a phone, eight of those on one page is a real risk of the browser discarding and re-decoding images as you scroll, which is visible as a flicker.
The two numbers worth checking before you publish
One: the actual width of the box the image is drawn into
Not the file's width — the displayed width. Use your browser's developer tools, inspect the element, and read the rendered size. On a responsive layout this changes with the viewport, so check at the widest breakpoint your layout supports. For a full-width hero on a 1440-pixel screen, an image around 1600 to 2000 pixels wide is usually right: enough for high-density displays, not absurd.
Two: whether the file is much bigger than it needs to be at that width
Once the dimensions are sensible, the remaining question is bits per pixel. A reasonable target for a photographic JPEG is roughly 0.5 to 1.5 bits per pixel. A 1200 × 900 photo should therefore land somewhere between about 70 KB and 200 KB. If it is 900 KB, something is wrong — either the quality setting is far too high or the file was never compressed.
The formula is worth remembering because it lets you spot the problem instantly without opening a tool:
bits per pixel = (file size in bytes × 8) ÷ (width × height)What about high-density displays?
Screens with two or three physical pixels per CSS pixel do exist, and serving a 1× image to them does look soft. The naive fix — serve 3× to everyone — triples your image weight for a benefit that only some visitors can see.
The right fix is srcset, which gives the browser a set of candidates and lets it choose based on
the device's pixel density and the current viewport width. The practical upshot: produce two or three
sizes, and let the browser pick. For a rendered width of 800 CSS pixels, that usually means 800, 1600 and
sometimes 2400 pixel versions.
If you are not in a position to change the markup, a single image at 2× the rendered width is a decent compromise: sharp on high-density screens, and still a fraction of the size of the original camera file.
The order to do things in
- Resize to the dimensions you will actually display. This is the big win, and it is where almost all the savings live. Use the image resizer and set a maximum width rather than an exact size, so the aspect ratio is preserved and odd-shaped images are not distorted.
- Pick the right format. Photographs as WebP or JPEG, screenshots and flat graphics as WebP or PNG. The reasoning is in the format guide.
- Only then adjust quality. And stop at the point where you cannot see a difference — for photographs that is usually around 75 to 80. More detail in the compression walkthrough.
Doing these out of order is the most common waste of effort in web performance work: carefully tuning compression settings on an image that is ten times larger than it needs to be.
A rough sense of scale
| Where the image goes | Reasonable width | Rough size target |
|---|---|---|
| Thumbnail, avatar, card | 200–400 px | 10–40 KB |
| In-article illustration | 800–1200 px | 60–200 KB |
| Full-width hero | 1600–2000 px | 150–400 KB |
| Anything you will zoom into | Whatever the detail requires | As large as it needs to be — but only then |
Those figures assume a photograph. A screenshot of a UI at the same rendered width will often be considerably smaller as a lossless PNG, because flat colour compresses so well.
Doing this without shipping the files anywhere
All of this is local work — measure, resize, convert, compare. The browser can do every step without a server round trip, which has the side effect that the process becomes fast enough to actually iterate: resize, look at it, adjust, look again. That rhythm is how you find the right size, and it is impossible when every attempt costs an upload.
The resizer and compressor here both work that way, on batches of files at once, with nothing leaving your machine.