Modern formats save real bandwidth: WebP is typically 25–35% smaller than JPEG at matched quality, and AVIF often 20–30% smaller again. The question is how to serve them without breaking older clients.
Option A: Markup-Based (picture + type)
Use a picture element with source children declaring their MIME types, most efficient first, then a plain img with the JPEG as the universal fallback.
How it works: the browser walks the sources in order and takes the first type it supports. It does not compare file sizes, so ordering is your decision, not an optimization the browser performs.
Pros: explicit, works on static hosting, no server logic, easy to reason about and debug. Cons: verbose markup everywhere, and every image needs multiple generated files committed or built.
Option B: Server-Side Content Negotiation
The server reads the browser's Accept header and returns AVIF, WebP or JPEG from the same URL.
Pros: your HTML stays simple — one img, one src. Caching and CDN transformation services often do this for you automatically. Cons: requires correct Vary: Accept handling or caches will serve the wrong format to the wrong client, which is a genuinely nasty bug.
Most CDNs and image services implement this well. If you're on one, prefer it; if you're on static hosting, use the markup approach.
Is AVIF Worth It?
- Compression: usually the best available, especially at low bitrates and on gradients and flat colour.
- Encode time: significantly slower than JPEG/WebP. For a build step over thousands of images, this matters; for a handful of hero images, it doesn't.
- Support: broad in current browsers, but not universal in older devices and some in-app webviews, so keep a fallback.
- Edge cases: AVIF can smooth fine detail and grain aggressively at low quality settings. For photography portfolios, compare at 100% rather than trusting the byte count.
A reasonable policy: AVIF plus WebP plus JPEG for high-traffic pages and hero images; WebP plus JPEG for everything else.
The Ordering Rule
Always most-efficient first: AVIF, then WebP, then the img fallback. Reversing that means supporting browsers happily take WebP and never see the AVIF.
Practical Cautions
- Keep quality settings per format. WebP quality 75 is not visually equal to JPEG quality 75; compare outputs rather than copying numbers across formats.
- Transparency: WebP and AVIF both support alpha, so a PNG fallback is needed only for very old clients.
- Don't transcode from an already-lossy JPEG when you can encode from the original; re-encoding stacks artifacts.
- Measure the result. Generating three formats for images that were already small wastes build time for negligible gain — spend the effort on the largest files first.