Most teams reach for a compressor when a page feels slow. Compression helps, but it treats a symptom. The real problem is usually that the browser is downloading and decoding an image several times larger than the space it will ever occupy. Until that mismatch is fixed, every other optimisation is polishing a leak.
The maths is brutal
Halving an image's width and height quarters its pixel count. A 4000 × 3000 photo carries 12 million pixels; the 1200 × 900 version your layout actually renders carries 1.08 million. That is roughly 90% of the work removed before a single compression setting is touched. No quality slider on earth can match simply not shipping pixels nobody will ever see.
“Compression makes each pixel cheaper. Resizing removes the pixels entirely.”
This is why an aggressively compressed 4000px image so often loses to a gently compressed 1200px one. The resized file starts from a fraction of the data, so it can use a higher quality setting — and still end up smaller and better looking.
Decode cost is invisible but real
Bytes are only half the story. Every image has to be decoded into memory before it can be painted, and decode time scales with pixel count, not file size. A 12-megapixel photo occupies roughly 48MB of raw bitmap in memory regardless of how small the JPG on disk is. On mid-range phones an oversized hero can block the main thread long enough to hurt Largest Contentful Paint even on a fast connection — and it can push other images out of memory entirely, causing visible re-paints as users scroll.
Retina changes the target, not the logic
The common objection is high-density screens: surely a 1200px slot needs a 2400px image for sharpness on retina displays? Yes — and that is still nowhere near 4000px. The rule is not “as small as possible”, it is “as big as the layout can actually use, and not one pixel more.” Export at 1× and 2× the rendered width, serve them with srcset, and every device gets exactly what it needs.
A workflow that holds up
- Measure the rendered width of the image slot in your layout — the CSS width, not the file.
- Export at that width, then again at 2× for retina screens.
- Only then apply compression — 75–85% quality is usually invisible.
- Prefer WEBP; it typically beats JPG by 25–35% at matching quality.
- Add width and height attributes so the browser reserves space and the page does not jump.
Run this sequence and the order matters: resize first, compress second. Compressing first wastes effort encoding pixels you are about to delete, and resizing an already-compressed file bakes artefacts into the smaller version.
How to spot the problem on your own site
Open your browser's developer tools, switch to the network panel, and reload the page. Sort by size. Any image whose natural width is more than double its rendered width is a candidate. Lighthouse flags the same issue as “Properly size images”, and page-speed tools will happily show you the wasted kilobytes per image.
What the gains look like in practice
Take a typical marketing page with a hero, three feature screenshots and four team photos — all exported straight from the camera or design tool at 3000–4000px wide. That page can easily weigh 8–12MB in images alone. Resized to their rendered widths and re-encoded as WEBP at 80%, the same eight assets commonly come in under 800KB total. That is not a marginal improvement; it is the difference between a page that feels instant and one that bleeds mobile visitors before the hero even paints.
The downstream effects compound. Core Web Vitals scores improve, which feeds search rankings. Bandwidth costs drop, which matters at scale. And because smaller images decode faster, interactions stay smooth on the low-end devices that make up a large share of real traffic.
Common misconceptions
“My host compresses images automatically” — some do, but compression without resizing still ships the oversized pixel count, and the decode cost lands on the user's device either way. “CDNs resize on the fly” — true for image CDNs, and a good solution if you have one; but most sites are not behind an image CDN, and the origin file is what gets served. “Users are on fast connections now” — connections are fast, but median phones are not, and decode time is the bottleneck that bandwidth cannot fix.
Make it a habit, not a project
The sites that stay fast are not the ones that did one big optimisation sprint — they are the ones where every image gets sized correctly before it is uploaded, every time. Build the two-minute resize into your publishing checklist the same way you proofread a headline. It is the cheapest performance win on the web, and it never stops paying off.
Resizely does the resizing step entirely in your browser, so you can run through a whole folder of heroes without uploading anything or waiting on a queue. Measure the slot, export the two sizes, compress at 80%, and watch the page-weight graph fall off a cliff.
