Image Quality Settings: How Small Is Too Small, and How to Decide Per Image

Compression quality is usually set once, by whoever configured the pipeline, and never revisited. Somebody types 80 into a config file because 80 is what people type, and every image on the site is treated identically from then on.

That works acceptably for photographs, which is most images on most sites, which is why the problem stays invisible. It fails badly for the minority of images where it fails, and those tend to be exactly the images carrying information.

Where the visible threshold sits

For photographic content in a modern format, the perceptual cliff is lower than most people assume. Between quality 75 and 85 you are generally in territory where a side-by-side comparison at display size shows no meaningful difference, while the file is a fraction of the size of a high-quality original.

Below roughly 65, smooth gradients start to band. Skies go first, then skin tones, then shadow areas. Above roughly 90, file size climbs sharply for detail that survives only under magnification.

So the default advice to sit around 80 is basically sound. The problem is treating it as the answer rather than as the answer for one kind of image.

Why the threshold moves

Lossy compression works by discarding information the eye is unlikely to miss. That model is tuned for photographs: continuous tone, soft transitions, natural noise. Content that violates those assumptions degrades much faster.

Content type	Behaves how	Practical setting	Better format
Photographs, natural scenes	Degrades gracefully	75–85	AVIF, then WebP
Photographs with large flat areas	Bands early in the flat regions	82–88	AVIF, then WebP
Screenshots of interfaces	Text fringes and smears	88–95, or lossless	WebP lossless, PNG
Diagrams, charts, line art	Edges ring and blur	Lossless	SVG if vector, else PNG
Logos and flat graphics	Halos around hard edges	Lossless	SVG
Images containing readable text	Worst case, fails visibly	90+, or lossless	WebP lossless

The pattern is that hard edges and flat colour are what lossy compression handles badly, and both are characteristic of anything informational rather than photographic. A screenshot at quality 80 has visibly mushy text. The same setting on a photograph of a workshop is indistinguishable from the original.

This is the entire argument for having two or three presets rather than one. You do not need per-image tuning. You need the pipeline to know the difference between a photograph and a screenshot, and the specific requirements of screenshots, diagrams and other non-photographic images go beyond compression alone.

Budgeting by page, not by file

Asking what a single image should weigh is the wrong question, because the browser does not load images one at a time in isolation. It loads whatever the page asks for, competing for the same connection.

A more useful frame is a budget for the first screenful:

• One hero, or one dominant image. This is usually the element that determines when the page looks loaded, so it deserves the most care and the highest priority. 80 to 200 KB in a modern format is a normal landing zone for a full-width image.
• Everything else above the fold: as little as possible. Logos, icons and decorative elements should be trivially small or vector. A 150 KB decorative flourish competing with the hero is pure cost.
• Below-the-fold images: deferred. These should not be fetched until they are near the viewport, at which point their individual size matters much less.

The reason to think in terms of the first screenful is that this is what the loading metrics actually measure, and the largest element in it is usually an image. How images determine Largest Contentful Paint is the mechanism underneath the budget, and it is worth understanding before optimising, because the most common wasted effort is aggressively compressing twenty below-the-fold images while the hero stays untouched.

Dimensions are also part of this, and often the larger lever. Serving a 2400-pixel-wide file into a 800-pixel-wide slot wastes most of the bytes regardless of the quality setting. Correct srcset and sizes attributes frequently save more than any compression change, because they stop the browser downloading detail it will never display.

The two silent failures

Double compression. A file gets optimised on upload by the CMS, then optimised again by the CDN on delivery. Each pass is individually reasonable and the combination produces artefacts neither would cause alone, most visibly as blocky patches in areas that were already smoothed once. The fix is not a better setting, it is knowing which single layer owns compression and feeding it originals.

Metadata loss. Most compression tools strip metadata by default, because removing it makes the file smaller and the tool has no way of knowing you wanted it. Descriptions, copyright fields and GPS coordinates vanish in a step nobody classified as destructive. If you have gone to the trouble of embedding anything, verify that your pipeline actually preserves image metadata rather than assuming it does, because the failure is completely silent.

That second one matters more than it sounds. What embedded EXIF data contributes and what it does not is a subject with a lot of overclaiming around it, but the baseline is simple: metadata that gets stripped somewhere between your desk and the served file contributes nothing at all, regardless of how carefully it was written.

Choosing the format

Format choice usually saves more than quality tuning. Moving photographic content from JPEG to AVIF or WebP at equivalent visual quality typically produces a substantially smaller file, which means you can often raise the quality setting and still ship less.

AVIF generally compresses better, especially on photographs. WebP encodes faster and has the longer support history. For most sites the sensible configuration is to serve AVIF where the browser accepts it and WebP as the fallback, rather than picking a winner. The detailed trade-offs between WebP, AVIF and JPEG matter most for large libraries, where encoding time and storage become real considerations rather than rounding errors.

One caution: if your pipeline converts formats on the way in, that conversion is also a compression step, and it is another place metadata quietly disappears.

Measuring whether it worked

Compression work generates a satisfying number — files got smaller by some percentage — that frequently has no relationship to whether anything improved for a visitor.

The number worth watching is the weight of what loads before the page is usable, not the total weight of every image on it. Halving the size of twenty below-the-fold images reduces total page weight substantially and changes the loading experience not at all, because those images were being fetched lazily and were never in the critical path. Meanwhile a hero left at 900 KB continues to determine when the page looks finished.

So the measurement sequence is:

1. Identify the element that determines perceived load. On most content pages it is the hero image, which is why it deserves disproportionate attention.
2. Record its transfer size and timing before changing anything. Without a baseline you are guessing.
3. Make one change at a time. Format, then dimensions, then quality. Changing all three at once tells you the combination worked without telling you which part mattered.
4. Re-measure on a throttled connection. Fast broadband hides the differences that matter most to the people experiencing them worst.

The usual finding is that dimensions and format account for most of the improvement and the quality slider accounts for surprisingly little. That is an argument for spending the effort on serving correctly sized modern-format files and then leaving the quality setting alone at a sensible default.

There is also a floor worth respecting. Past a certain point you are trading visible quality for savings measured in single-digit kilobytes, which is a bad trade on any page where the image is doing real work.

A last caution on tooling: measure the file as served, not the file on disk. If a CDN re-encodes on delivery, the bytes leaving your build system and the bytes arriving at a browser are different files, and optimising the first while ignoring the second is a common way to spend a day achieving nothing.

A workable default

If you want one configuration to start from rather than a philosophy:

1. Photographs: AVIF at quality 80, WebP fallback at 82. Revisit only if something looks wrong.
2. Screenshots and anything with text: WebP lossless, or quality 92 if size is critical. Never the photographic setting.
3. Logos, icons, diagrams: SVG where possible, lossless PNG otherwise. These should not be going through a photographic pipeline at all.
4. Serve responsive sizes. This saves more than the quality setting on most pages.
5. Check metadata survives. Once, on one file, end to end from source to served URL.

Then look at the result on a real page at real size, which is the only test that counts. Zooming to 200 percent to hunt for artefacts finds differences no visitor will ever see and leads directly to shipping files twice the necessary size.

The broader point is that compression is one item on a longer list, and getting it perfect while the filename is IMG_4021 and the alt attribute is empty is optimising the wrong thing. A short pre-publish checklist covering everything an image needs puts the quality setting in proportion. Where SEOpix fits is the other end of this: images arrive already carrying descriptive filenames and embedded metadata, so the only decision left at publish time is how hard to compress them. See how that works, or generate ten free.