AVIF (and modern image formats)

AVIF (AV1 Image File Format) is an “open, royalty-free” modern image format — the most direct lever on the single biggest slice of page-weight. The Web Almanac put images at ~1,054 KB, the largest component of the median page; better image compression is therefore the highest-leverage byte saving. Source: Wikipedia.

The compression advantage

Per Netflix testing, “AVIF showed better compression efficiency than JPEG as well as better detail preservation, fewer blocking artifacts and less color bleeding” — and it beats WebP too. Browser support is now broad: “all the major web browsers (over 93% … by use)” (Chrome 85, Firefox 93, Safari 16, Edge 121). So the legacy-JPEG default is now a defensible budget target to replace.

How much smaller? Two Google/MDN sources put a number on it. web.dev’s headline is “greater than 50% savings vs. JPEG”, with the caveat the win is content-dependent (web-dev-compress-images-avif). MDN sharpens the ranking against WebP: median 50% (AVIF) vs 30% (WebP) compression for the same JPEG set — so the lever order is AVIF > WebP > legacy JPEG (mdn-image-types).

More than a JPEG replacement

AVIF is an AV1 bitstream in a HEIF container, and it carries the features that let it replace PNG and animated GIF too, not only JPEG (mdn-image-types):

• Alpha-channel transparency — so it covers the PNG use case.
• Animation (multi-image) at “much better compression” than animated GIF.
• HDR, wide color gamut, and film-grain synthesis (model the grain instead of storing it) (web-dev-compress-images-avif).

The one caveat: no progressive rendering — “files must be fully downloaded before they can be displayed” (mdn-image-types), so a too-large AVIF blocks paint rather than degrading gracefully. Keep the file genuinely small.

The encode-cost tradeoff

AVIF’s cost is encode time, which is why it belongs at build time / on a CDN, not per request — the same compress-once-serve-many pattern as brotli. web.dev documents libaom cutting memory ~5× and CPU ~6.5× between 2.0.0 and 3.1.0, with multi-threading adding “roughly 5×” (web-dev-compress-images-avif).

Why it matters here

This is the concrete mechanism behind the wiki’s page-weight thesis: serving AVIF/WebP instead of JPEG/PNG (with <picture> fallbacks) cuts the dominant byte category — exactly the kind of efficient delivery the cross-wiki page-weight-vs-architecture debate says drives real-world performance. Format choice, not just fewer images. Because AVIF support “has little historical depth,” MDN’s rule is to ship it as a progressive enhancement behind a <picture> element with WebP/JPEG/PNG fallbacks (mdn-image-types) — never a hard swap.

Related

page-weight · web-almanac-page-weight-2024 · web-dev-compress-images-avif · mdn-image-types · brotli · performance-budget · bundle-size · core-web-vitals