Smaller file, faster page — except when it isn't. Decode time, encode time and the caching your benchmark forgot all decide which format actually wins.
The received wisdom is short: AVIF makes smaller files than WebP, smaller files download quicker, therefore AVIF is faster. Every line of that is roughly true and the conclusion is still often wrong. "Faster" isn't one measurement — it's at least three clocks running at once, and file size only stops one of them. The other two, how long the browser takes to decode the image and how long your build takes to encode it, frequently run in AVIF's disfavour. Which format wins depends entirely on which clock your users are actually waiting on.
Here's the honest version, one clock at a time.
Clock 1: bytes on the wire — AVIF's home turf
This is the number everyone quotes, and it's the one AVIF genuinely wins. At matched visual quality, AVIF files are commonly 20–30% smaller than WebP, and the gap widens on exactly the images that hurt most: large photographic heroes, gradients, and smooth skies where AVIF's newer compression (it's derived from the AV1 video codec) simply models the content better. If your bottleneck is a first-time visitor on a slow mobile connection pulling a 2 MB hero, fewer bytes is the whole ballgame and AVIF pulls ahead.
But notice the assumptions hiding in "download quicker." They only hold on the first uncached visit, on a connection where bandwidth is the constraint. On a warm cache the transfer is zero bytes and this clock reads zero for both formats. On a fast connection, shaving 40 KB off a request that was going to arrive in 15 ms anyway saves you a few milliseconds nobody perceives. The byte-size win is real, but it's loudest precisely in the worst-case scenario and near-silent in the common one.
Clock 2: decode time — where WebP quietly wins
A downloaded image isn't a visible image. The browser still has to decode the compressed bytes into pixels before anything paints, and this is the clock the size benchmarks almost always ignore. AVIF's cleverer compression is not free: it is more expensive to decode than WebP, and dramatically more expensive than JPEG. On a fast laptop you won't notice. On a budget Android phone — the device most likely to be on the slow connection where you reached for AVIF in the first place — decoding a large AVIF can take noticeably longer than decoding the slightly larger WebP would have.
This creates a genuinely counter-intuitive outcome: AVIF wins the transfer, loses the decode, and the total time-to-paint can land in WebP's favour on low-end hardware. The crossover point depends on image dimensions and CPU. A small thumbnail decodes so fast in either format that the byte savings dominate and AVIF wins cleanly. A full-screen 4K hero on a cheap phone is where AVIF's decode cost is most likely to eat its download savings. The rule of thumb: the bigger the image and the weaker the device, the more the decode clock matters relative to the size clock.
Clock 3: encode time — the one your build feels
There's a third clock, and it doesn't run on the user's device at all — it runs in your build pipeline, and it's the one that quietly wrecks deploy times. Encoding AVIF at a quality that actually beats WebP is slow. Depending on the "effort" or "speed" setting you pick, a high-quality AVIF encode can take several times longer than the equivalent WebP encode — sometimes an order of magnitude on the slowest, smallest-file settings.
For a handful of hero images this is a non-issue; you encode once and serve forever. For a photo gallery, a product catalogue, or any pipeline converting thousands of images on every deploy, AVIF's encode cost turns a two-minute build into a twenty-minute one. Turn the encoder speed up to compensate and you throw away much of the file-size advantage that was the whole point. WebP's encoder, by contrast, is fast and forgiving, which is a real operational advantage that never shows up in a "which is smaller" comparison.
So which is actually faster?
Stack the three clocks and the answer stops being a single winner:
- Large hero images, served to first-time mobile visitors, encoded once: AVIF. The byte savings are large, the decode happens once per visit, and the slow encode is amortised across every future view. This is AVIF's best case and it's a good one.
- High volume of images, encoded on every build (galleries, user uploads, catalogues): WebP, usually. The encode-time and decode-time costs of AVIF compound at scale, and WebP's smaller-but-still-substantial savings come without the operational tax.
- Small images — thumbnails, icons, avatars: a near-tie where the decode difference vanishes; pick WebP for the faster encode and broader tooling unless you're already all-in on AVIF.
- You can only ship one format with no fallback: WebP, still, in 2026. Its browser support is effectively universal and its performance is predictable across the low-end devices AVIF punishes hardest.
The answer that dodges the question: ship both
The honest professional move is not to choose. The HTML <picture> element lets you offer AVIF first with a WebP fallback, and every browser takes the best format it can decode:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="…">
</picture>
You pay the encode cost twice at build time and hand the runtime decision to the one component that actually knows the user's device and cache state: their browser. For high-value images — the hero, the above-the-fold shots — this is almost always the right call, and it sidesteps the entire "which is faster" argument by letting each user get whichever one is faster for them.
Measuring it yourself, without the benchmark theatre
The single-number benchmarks that started this whole debate are misleading because they report one clock — usually file size — and call it speed. If you want the real answer for your images, the experiment is cheap. Take a representative image and convert it to both AVIF and WebP at a quality you can't visually fault, and compare the actual file sizes rather than a blog's averages — your content may compress nothing like the sample photos benchmarks use. Run the same source through a compressor to find the quality floor before artefacts appear, since the byte gap between the formats changes with quality. If you're serving responsive images, resize to the dimensions you'll actually ship before comparing — the format that wins at 4K may lose at thumbnail size. And strip metadata with an EXIF remover first so you're measuring the picture, not a few kilobytes of embedded camera data that inflate both files equally. Every one of those runs in your own browser, on your own image, which is the only benchmark that answers your actual question.
AVIF is smaller. WebP is faster to decode and encode. Neither of those facts wins the argument alone — your image sizes, your users' devices, and your build pipeline do. Measure the clock your users are waiting on, and let that pick the format.
← All articles