Efficiently Encode Images: Compress Without Killing Quality

This check flags images that are not efficiently compressed, files carrying more bytes than the visible quality requires. A JPEG saved at quality 100, a photograph stored as a PNG, a 4000px original squeezed into a 400px thumbnail, all move data the user never benefits from. Trimming that fat cuts page weight, speeds up load, and lightens the largest contentful paint, usually without a pixel of visible difference.

What this check flags and why it matters

The audit compares each image's delivered size against what an efficiently encoded version would weigh and flags the gap. Images are the heaviest thing on most pages, so an un-optimised image library is often the single biggest chunk of wasted bandwidth on a site. The stakes are slower loads on mobile, a worse LCP when the offender is the hero, and real data cost for visitors, all recoverable with encoding choices that cost you nothing in perceived quality.

A real before-and-after

A photographer's portfolio served hero shots as quality-100 JPEGs straight from the camera, roughly 2.4 MB each. Re-encoding at quality 82 and resizing to the real display width brought them to about 240 KB, a tenth of the weight, indistinguishable on screen. Same tools, run from the command line, that make the fix repeatable:

# Resize to real display width and re-encode JPEG at a sane quality
cjpeg -quality 82 -optimize input.jpg > output.jpg

# Or with ImageMagick: resize + strip metadata + quality in one pass
magick input.jpg -resize 1200x -strip -quality 82 output.jpg

# WebP, typically 25-35% smaller than JPEG at equal quality
cwebp -q 80 input.jpg -o output.webp

Quality 80 to 85 is the sweet spot for photographs, small enough to save real weight, high enough that nobody notices. Below about 70 you start seeing artefacts.

Pick the right format first

Half of efficient encoding is choosing the format that suits the image. The wrong format wastes bytes no quality setting can recover.

How to detect it

1. PageSpeed Insights: run the URL and open the "Efficiently encode images" opportunity, which lists each oversized file with the potential byte savings.
2. Lighthouse: the same audit in Chrome DevTools under Performance, plus "Properly size images" and "Serve images in next-gen formats", which usually appear alongside it.
3. curl: check the real transfer size of a suspect image without downloading the whole thing:

   curl -sI -A 'Mozilla/5.0' https://example.com/hero.jpg 
     | grep -i content-length

   Anything over a few hundred KB for a standard content image is worth a look.

4. DevTools Network panel: sort requests by size and let the biggest images rise to the top, that is your priority list.

How to fix it

Work in this order. Resize every image to the largest size it is actually displayed at, no 4000px files in a 600px column. Choose the format that fits the content from the table above. Compress to quality 78 to 85 for photos, lossless for graphics and text. Strip EXIF and colour-profile metadata you do not need. Then automate it, an image-optimisation plugin or a build step so new uploads never reintroduce the problem. On WordPress, a compression plugin plus correctly sized theme image dimensions handles most of this without touching individual files. Related fixes: serve images in next-gen formats to go beyond JPEG, enable text compression for the non-image bytes, and improve LCP when the worst offender is your hero.

FAQ

What quality setting should I use for JPEG and WebP?

For photographs, 78 to 85 is the practical range, real savings with no visible loss. Below 70 artefacts creep in; above 90 you pay in bytes for quality nobody perceives on a screen. Test on your own images, since ideal quality varies with subject and noise.

Will compressing images make them look worse?

Not at sensible settings. Lossy compression at quality 80-plus is visually indistinguishable from the original for most photos while cutting weight dramatically. The visible-damage risk only shows up when you push quality too low or re-compress an already-compressed file repeatedly.

Is this the same as serving next-gen formats?

Related but distinct. Efficient encoding is about compressing whatever format you use to a sane weight; next-gen formats are about switching from JPEG/PNG to WebP or AVIF, which are smaller at equal quality. Do both, they stack.

Should I resize images or just compress them?

Both, and resizing usually wins the bigger saving. Serving a 3000px image into a 500px slot wastes the majority of the bytes before compression even enters the picture. Resize to display size first, then compress.

Can I automate image optimisation?

Yes, and you should. A build-step tool or a CMS plugin re-encodes every new upload automatically, so the fix holds instead of decaying as the team adds fresh images over time.