Use AVIF to compress images (web.dev)

Google web.dev’s guide to encoding avif, the AV1-based image format. It backs the wiki’s claim that better image compression is the single highest-leverage cut on page-weight (images ≈ 1,054 KB of the median page, per web-almanac-page-weight-2024).

The savings figure

web.dev’s headline: “greater than 50% savings vs. JPEG”, with the caveat that the exact figure “will depend on the content, encoding settings, and quality target.” (It also shows a near-tie example — an 1120×840 image at 18,769 bytes AVIF vs. 20,036 bytes JPEG, ~6% — to make the point that the win is content-dependent, not automatic.)

Features it highlights

• High Dynamic Range and Wide Color Gamut.
• Film-grain synthesis — model grain rather than store it, saving bytes on photographic content.
• Progressive decoding in two forms: spatial scalability (resolution builds up) and quality scalability (detail builds up).

The encoding-cost caveat

AVIF’s downside is encode time. web.dev documents libaom’s progress: between 2.0.0 and 3.1.0, a 5× reduction in memory and 6.5× reduction in CPU (at speed=6, cq-level=18 on 8.1 MP images); multi-threading with --jobs 8 gives “roughly 5×” more. So the practical pattern is the brotli pattern in image form — compress once (expensively), serve many times — and serve via an image CDN.

Why this matters here

This is the concrete encoder-side companion to the avif concept page: it pins the “≈50% vs JPEG” number to a Google source and surfaces the encode-cost tradeoff that makes AVIF a build-time / CDN job, not a per-request one. See synthesis on the delivery layer.