Guide
The image compression checklist
Most sites lose weight in the same three places: images that are far larger than their layout slot, formats chosen out of habit, and caching that throws away the work. Work down this list in order — each step costs less effort than the one before it and saves more.
1. Fix the dimensions before you touch quality
A 4000-pixel photo in a 400-pixel card is eleven times more pixels than the layout can show. Resize first: it removes more bytes than any quality slider and cannot introduce artefacts. Match the largest size the layout renders, doubled for high-density screens.
2. Choose the format by content, not by habit
Photographs: WebP, with AVIF where support allows. Screenshots, diagrams and icons: lossless WebP, or PNG when you need universal compatibility. Anything that must open in unknown software: JPEG. Animated content: WebP or AVIF, not GIF.
3. Find the quality floor with your eyes, not a default
Defaults are conservative. For photographs, quality 75–85 is usually indistinguishable at display size, and the file is a third of the size. Open the preview next to the original, look for banding in skies and mush in fine texture, and stop one step above where artefacts appear.
4. Ship fallbacks, not experiments
Use <picture> with AVIF, then WebP, then JPEG. Browsers pick the first source they support, so nothing breaks and newer browsers get the small file. Never ship a single AVIF without a fallback.
5. Do not re-encode the same image twice
Every lossy pass costs quality. Compress once, from the original, and keep that original. Tools that “optimise again” on every deploy quietly degrade your archive.
6. Strip metadata you do not need
EXIF can carry GPS coordinates, camera serial numbers and editing history. Encoders in this app write fresh files without it, which is both smaller and safer for anything user-generated.
7. Cache what you already paid to compress
Content-hashed assets should be served with a one-year immutable cache. Images on a CDN deserve the same treatment. Regenerating or re-downloading them on every visit wastes the compression you just did.
8. Measure, then stop
Check the largest image on your heaviest page, not the average. Lighthouse and the network panel both show transferred bytes; pick the one image that dominates and fix that one. Most sites are done after three files.
What to expect
| Step | Typical saving | Effort |
|---|---|---|
| Resize to layout size | 60–90% | minutes |
| Switch to WebP | 25–35% vs JPEG | minutes |
| Lower quality to the visual floor | 20–50% | seconds |
| Add AVIF for modern browsers | 20–40% more | minutes |
| Immutable caching | eliminates repeat downloads | config |
Questions
Should I compress images at build time or on the fly?
Build time, for anything that does not change per user: it is cheaper, cacheable and reviewable. On-the-fly transforms make sense for user uploads on the edge, not for your own assets.
Is lossless always the safe choice?
It is safe for the pixels, not for performance. Lossless PNG or WebP can still be several times larger than a well-chosen lossy encode that nobody can tell apart at display size.
How many sizes of each image should I generate?
Two or three: the layout width, a 2× version, and occasionally a small mobile crop. Beyond that the maintenance cost outweighs the bytes saved.