Short answer: compress images for the web by making the source trustworthy, creating only useful dimensions, choosing a quality and format policy that survives visual review, and letting the browser receive an appropriate candidate early enough to be useful.
1. Measure the layout slots
Begin with the places an image appears, not the original upload dimensions. A card image, article hero, product detail image, and mobile crop may need different widths or even different compositions. Measure rendered widths across your real layouts and group nearby values into a small candidate ladder.
Responsive markup is the handoff between that ladder and the browser. srcset provides candidates and sizes describes the likely layout slot. The MDN responsive image guide is a useful reference, but test the selected network request in the actual page because an inaccurate sizes value causes predictable over-download.
2. Make a visual quality decision
Encode a representative set at the dimensions users will receive. Put difficult images beside easy ones: gradients, product edges, hair, low-light photography, text embedded in an image, and transparent graphics. View the files in the page, not only in a file browser.
If the source is photographic, a controlled lossy output may be appropriate. If it contains exact text, critical transparency, or pixels that cannot change, a lossless path may be safer. See lossy vs lossless image compression for the decision framework.
3. Load the critical image intentionally
The LCP image should generally be discoverable in the initial HTML and should not use lazy loading. Reserve its width and height so the page does not shift. Below-the-fold media can defer transfer through native lazy loading when it will not delay the user’s next useful action.
The web.dev LCP guide explains why discovery and loading policy are part of the outcome. Compression is not only about bytes: an image that arrives late can still be a poor delivery.
4. Keep cache behavior simple
Do not create arbitrary width, quality, and crop values for every request. Define approved dimensions and transformation recipes. Version a recipe when output behavior changes, keep sources separate from derivatives, and make it possible to trace a delivered URL back to the source and rule that created it.
Cloudinary documents automatic format and quality at delivery with f_auto and q_auto; its documentation also notes that browser-dependent format selection belongs in delivery, not an incoming or named transformation. The same principle applies to any platform: retain a small, explicit delivery vocabulary.
5. Verify the result
Read transfer bytes beside rendered dimensions, request timing, LCP contribution, cache evidence, and a visual check at the target size. Re-test after a layout or transformation change. That feedback loop keeps a compression win from turning into a visual or operational regression.
For the broader decision model, return to the practical image compression guide.
A release checklist
Before release, confirm that the likely LCP image is eager and discoverable, offscreen images are not delaying the first view, dimensions are reserved, and each layout uses a truthful sizes value. Inspect a small and wide viewport, then use browser network tools to see which candidate was selected. A screenshot alone cannot prove that the delivery path is efficient.
After release, compare the plain canonical page with a cache-busted request and a fresh browser context. Server, CDN, plugin, and browser caches can disagree. If the bypassed response is correct but the canonical page is stale, invalidate the intended cache layer rather than declaring the compression change complete.
Keep the pipeline small enough to operate
Every extra width, quality setting, crop rule, or query parameter creates more derivatives and more cache objects. Start from observed layout demand, round dimensions to an approved ladder, and centralize transformation choices. The policy should be boring enough that a new team member can explain why a delivered URL exists.
When the experience changes, return to the source, slot, candidate, and measurement rather than applying a global quality reduction. That makes the next improvement a controlled change instead of a new mystery.