Serve Images in Next-Gen Formats (WebP/AVIF): How to Fix It

TL;DR — This audit fires when you're still serving JPEG or PNG where WebP or AVIF would deliver the same picture at a fraction of the bytes. Images are usually the heaviest thing on a page, so shipping them in an old format directly inflates load time and Largest Contentful Paint on the exact element users are waiting to see.

What this check flags

Lighthouse compares each image against a modern-codec version and reports the bytes you'd save by switching. WebP typically cuts 25–35% off a comparable JPEG; AVIF often cuts 50% or more at similar visual quality. On an image-heavy page that difference is measured in megabytes, and because the hero image is frequently the LCP element, the format you choose there decides how fast the page feels.

A real example, and the fix

A product page ships a hero as a plain JPEG:

<img src="/img/hero.jpg" width="1200" height="675" alt="Trail runner mid-stride">
<!-- 480 KB -->

Encode modern variants and let the browser pick the best one it supports, falling back cleanly to JPEG on anything that can't decode AVIF or WebP:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" width="1200" height="675"
       alt="Trail runner mid-stride" fetchpriority="high">
</picture>
<!-- AVIF ~180 KB, WebP ~300 KB, JPEG fallback preserved -->

Same picture, roughly 60% fewer bytes for browsers that support AVIF, and zero risk for the ones that don't.

Which format wins where

WebP and AVIF are not interchangeable, and JPEG/PNG still have narrow jobs. Pick per image type rather than converting everything blindly.

How to detect it

1. Lighthouse / PageSpeed Insights: open "Serve images in next-gen formats" under Opportunities. It lists each legacy image with the estimated byte savings, so you know exactly which files to convert first.
2. DevTools Network tab: reload with the Network panel open, sort by size, and filter to Img. Anything large with a .jpg or .png extension and a Content-Type of image/jpeg or image/png is a conversion candidate.
3. Response headers check: confirm the server actually serves the modern format by checking the Content-Type header of the delivered image — a .webp URL that returns image/jpeg means your pipeline isn't doing what you think.

How to fix it

1. Convert at the source. Batch-encode your library to AVIF and WebP with sharp, cwebp/avifenc, or your build pipeline, keeping the original as a fallback.
2. Serve with <picture> or content negotiation. Either list <source> variants by type, or have your CDN read the Accept header and return the best format automatically.
3. Let a CDN do it on the fly. Image CDNs (Cloudflare Images, Cloudinary, imgix) can transcode and resize per request, so you don't maintain variants by hand.
4. Keep dimensions and priority right. Always set width/height to prevent layout shift, and add fetchpriority="high" to the LCP image so the format win actually lands on the metric.
5. Pair with lazy loading below the fold. Combine next-gen formats with lazy loading so offscreen images don't compete with the hero for bandwidth.

Why this one moves LCP more than most

Most performance audits shave milliseconds off scripting or rendering. This one attacks the single heaviest byte payload on a typical page, and that payload is often the LCP element itself. Cutting a 480 KB hero to 180 KB means the browser finishes downloading and painting the thing users are staring at far sooner — which is why format work shows up so cleanly in LCP improvements. It pairs naturally with deferring offscreen images and the broader discipline covered in image optimization: right format, right dimensions, right loading priority.

FAQ

Is AVIF always better than WebP?

For compression at a given quality, usually yes — but AVIF encodes slower and decodes a touch heavier on very old devices. Serve AVIF first with WebP as the middle fallback and JPEG as the floor, and you get the best of all three.

Will next-gen formats break older browsers?

Not if you use <picture> with a JPEG/PNG <img> fallback. Any browser that can't decode AVIF or WebP silently falls through to the legacy source. Support for both formats is now near-universal on current browsers regardless.

Does converting to WebP hurt image quality?

At sensible quality settings (around 75–80), the difference is invisible for photos while the file is far smaller. Compare a converted sample against the original before committing your encoder settings.

Should I convert PNGs too?

Yes, especially large ones. WebP and AVIF both support transparency and usually beat PNG on size. Keep PNG only for tiny assets where the overhead isn't worth it, or move simple graphics to SVG.

My images are already WebP but the audit still fires — why?

Either the server is serving them with the wrong Content-Type, or Lighthouse thinks AVIF would save meaningfully more. Check the delivered header, and consider adding an AVIF tier for your largest images.