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

What this means

Lighthouse flags "Serve images in next-gen formats" when it finds images encoded as older formats (JPEG, PNG, GIF) that could be delivered as WebP or AVIF instead. These newer formats use more efficient compression, so the same picture downloads as a much smaller file and paints sooner. This is a recommendation, not a hard error: the page still works, but it ships more bytes than it needs to, and for sites that lean on photography, product shots, or hero banners those savings add up quickly.

Why it matters

According to web.dev, AVIF and WebP have superior compression and quality compared with JPEG and PNG, with file-size reductions commonly in the 25 percent to 50 percent range at equivalent quality. Smaller images mean faster loads and less cellular data for mobile visitors.

Images are often the heaviest assets on a page, so they are frequently the Largest Contentful Paint element, which makes shrinking them one of the highest-leverage fixes for Core Web Vitals. See our LCP complete guide for how image weight feeds into loading speed, and keep width and height attributes in place so converting formats does not introduce layout shift, covered in our CLS complete guide.

How it gets flagged

Lighthouse runs this as part of the Performance audit. It estimates the byte savings if each eligible JPEG or PNG were re-encoded as WebP, then lists the offending image URLs alongside the projected reduction. PageSpeed Insights, Sitebulb, and most site-audit crawlers surface the same audit under a similar name.

How to fix it

1. Convert your images

Generate WebP or AVIF copies of your existing assets. Command-line tools such as cwebp and avifenc handle this, as do build-step tools like Imagemin. AVIF usually produces the smallest files; WebP is a safe, widely supported baseline.

2. Serve them with a fallback

Use the <picture> element so each browser picks the best format it understands and older browsers still get a working image:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Descriptive alt text"
       width="1200" height="675" loading="lazy">
</picture>

The browser reads the sources top to bottom and uses the first format it supports. The <img> tag is the universal fallback and is where your alt text, dimensions, and lazy-loading live. Keep width and height on the image to reserve space and avoid layout shift.

3. Use an image CDN or a plugin

If hand-editing markup is impractical, let infrastructure do it. An image CDN (Cloudflare Images, Cloudinary, imgix, or similar) converts and serves the right format automatically based on the visitor's browser. On WordPress, plugins such as Imagify, ShortPixel, EWWW, or Smush convert your media library to WebP or AVIF and rewrite your image tags for you, with no manual <picture> editing. For a broader approach, read our image SEO complete guide.

Browser support note

WebP is supported in current versions of Chrome, Firefox, Safari, Edge, and Opera, so it is safe as a near-universal target. AVIF is supported in Chrome, Edge, Opera, and Firefox, and in Safari since 2022. Because the <picture> pattern always includes a JPEG or PNG fallback, even visitors on a browser that recognizes neither format still see the image. You lose nothing by adopting these formats.

False positives

A few situations make this audit fire when there is little to gain:

• Very small images (icons, sprites, tiny thumbnails) where the conversion savings are negligible and not worth the extra build complexity.
• Images already optimized at the byte level where Lighthouse still estimates a theoretical WebP saving but the real-world difference is trivial.
• Third-party or ad-network images you do not control and cannot re-encode.
• SVG graphics, which are already a vector format and should not be converted to WebP or AVIF.

Fix the large, in-content images first. Those are where the speed gains actually live.

FAQ