How to Serve Next-Gen Image Formats in 2026

If you've run PageSpeed Insights on any site in the last five years, you've seen "Serve images in next-gen formats" as a recommendation. Here's what it means, why it matters, and three ways to actually deliver them.

What "next-gen formats" means

Google's umbrella term for WebP, AVIF, and JPEG XL. The first two are deployed everywhere in 2026. JPEG XL is in a slow rollout and still patchy in Chrome.

For practical purposes: serve AVIF as the primary format, WebP as a fallback for the handful of browsers without AVIF, and JPEG as the ultimate fallback.

Why Google cares

Smaller images mean faster page loads. PageSpeed's audit is essentially: "you could save N kB of bandwidth by using WebP or AVIF instead of JPEG/PNG." Their suggested savings come from a side-by-side encode comparison done at build time.

The real-world payoff:

• Faster LCP (Largest Contentful Paint): a hero image at 600 KB vs 1.8 MB renders ~1 second faster on a 3G connection.
• Lower CDN bills: half the bytes per request.
• Better mobile UX: same scroll experience on a poor connection.

Three delivery methods

Method 1: Pre-encode and use <picture>

The traditional approach. Encode every image to multiple formats at build time, serve via <picture> with <source> fallbacks. Maximum control, zero runtime cost, works without a CDN.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1600" height="900">
</picture>

Tools: encode with AVIF Converter, PNG to WebP, or Image Compressor.

See How to Use the HTML Picture Element for the full syntax.

Method 2: CDN auto-conversion

Cloudflare Images, Bunny Optimizer, Imgix, Fastly's Image Optimizer, all auto-detect the browser's Accept: image/avif,image/webp,... header and serve the right format.

You upload JPEGs, the CDN delivers AVIF or WebP based on what the visitor's browser supports.

Pros: zero ongoing maintenance, automatic responsive sizes, no <picture> boilerplate. Cons: monthly cost, vendor lock-in, your images live on someone else's infrastructure.

Method 3: Server-side conversion

Nginx with the ngx_pagespeed module, or a Laravel/Node middleware that converts on demand. The server reads the Accept header and serves AVIF/WebP if supported.

Pros: full control, no CDN dependency. Cons: encoding latency on first request per image (cache it!), CPU cost on the server.

Which method to pick

• Static site, low traffic: Pre-encode with <picture>. Free, fast, no surprises.
• CMS site (WordPress, Ghost), any traffic: Cloudflare or similar CDN auto-conversion. Quick to set up, scales.
• Custom app, high traffic: Server-side conversion with aggressive caching, or a CDN. Decide based on whether you trust the CDN with your image library.

Workflow recommendation

For most teams in 2026:

1. Pre-encode the critical above-the-fold images (hero, first content block). Use <picture> to guarantee they're served as AVIF/WebP. This locks down LCP performance.
2. Use CDN auto-conversion for everything else. Cloudflare's image transformations handle the long tail without you having to think about formats.
3. Lazy-load everything below the fold with loading="lazy".
4. Set width and height on every <img> to prevent layout shift.

Browser support summary

In 2026, AVIF and WebP are both safe defaults. Don't ship JPEG XL until Chrome enables it without a flag.

Encoding settings

• AVIF: quality 50-65 for photos. Default 60 in AVIF Converter is the sweet spot.
• WebP: quality 75-85 for photos. Default 80 in PNG to WebP.
• JPEG fallback: quality 80-85. Default in Image Compressor.