Serve images in next-gen formats (WebP/AVIF)

What’s actually happening

PageSpeed lists each legacy JPEG/PNG with the KiB you’d recover by switching to WebP or AVIF. The savings are often larger than “Properly size images” because the format change alone can cut 25–50%+ at equal quality. Slow image bytes show up as a late-arriving LCP element — the hero image is usually both the largest image and the LCP candidate.

Common causes

• Images stored and served as JPEG/PNG with no modern-format version generated.
• PNG used for photographic content (huge files) where a lossy WebP/AVIF would be a fraction of the size.
• No content negotiation — the server sends the same JPEG to every browser even when it accepts AVIF.
• A CMS/theme that uploads originals unchanged and never produces .webp/.avif derivatives.
• Build pipeline lacks an image-conversion step.

How to fix it

1. Convert the assetsBatch-convert with cwebp -q 80 in.jpg -o out.webp and avifenc in.jpg out.avif, or use sharp/squoosh in a build step. AVIF compresses hardest; WebP is the safe broad default. Keep the original as a fallback.
2. Serve with a <picture> fallback<picture><source type="image/avif" srcset="img.avif"><source type="image/webp" srcset="img.webp"><img src="img.jpg" alt=""></picture>. The browser takes the first format it supports and falls back to the JPEG, so old clients still get an image.
3. Or let an image CDN auto-negotiateCloudflare Polish, Cloudinary f_auto, imgix auto=format, or next/image read the Accept header and ship AVIF/WebP to browsers that support it and JPEG to those that don’t — no <picture> markup needed.
4. Tune quality, don’t crank itq=75–85 is usually visually lossless for photos and far smaller. Inspect a few converted images at full zoom for banding/artifacts before rolling out a low quality setting site-wide.
5. Verify deliveryReload the page and check the Network tab — the Type column should read webp/avif, not jpeg. If you still see JPEG, content negotiation or the <picture> source order isn’t taking effect.