WebP vs AVIF: Decode Cost Flips the Winner
AVIF compresses more than WebP. But on low-end phones, its decode cost eats the savings. This post shows the head-to-head data across file size, decode, download, and five decision criteria.
What we asked
AVIF compresses more than WebP. That is well documented. But compression is only one axis. We wanted the full picture: file size, decode cost, download time, and combined time-to-paint across CPU tiers and network profiles.
The question: does AVIF’s higher compression translate to a faster serving experience, or does the decode cost eat it?
How we measured
Two experiments from the benchmark overview apply here:
- Experiment A (3,375 runs): decode cost on localhost, 3 CPU tiers (1x desktop, 4x mid-tier, 6x low-end), no network noise.
- Experiment B (2,250 runs): full CDN route, 2 network profiles (fast 4G, slow 3G), cold/warm cache per run.
75 production images (25 JPEG, 25 GIF, 25 PNG). Each image converted to WebP and AVIF at quality q80. Every run uses a fresh incognito context. CDP (Chrome DevTools Protocol) controls CPU throttle and network emulation.
What we found
File size savings (higher is better)
p25 / p50 / p75 are quartiles across the 25 images per source format. Half the images save at least the p50 value.
| Source | Target | p25 | p50 | p75 |
|---|---|---|---|---|
| JPEG | WebP | 45.1% | 47.1% | 53.3% |
| JPEG | AVIF | 33.7% | 38.2% | 43.8% |
| GIF | WebP | 41.1% | 51.0% | 61.6% |
| GIF | AVIF | 46.6% | 54.0% | 63.3% |
| PNG | WebP | 81.1% | 82.9% | 85.6% |
| PNG | AVIF | 79.4% | 81.0% | 85.1% |
WebP compresses JPEG and PNG more than AVIF at the same q. AVIF compresses GIF more (54% vs 51%), but the gap is 3 points. On file size alone, neither format dominates.
Decode time (lower is better)
Decode time is the CPU work to turn downloaded bytes into pixels. The img.decode() API measures it in isolation, with no network in the loop.
| CPU tier | Original (p50) | WebP (p50) | AVIF (p50) |
|---|---|---|---|
| Desktop (1x) | 1.2 ms | 2.2 ms | 7.6 ms |
| Mid-tier phone (4x) | 1.6 ms | 2.5 ms | 3.9 ms |
| Low-end phone (6x) | 2.3 ms | 3.4 ms | 31.9 ms |
On the desktop row, AVIF decode is 7.6 ms. That is acceptable. On the low-end row, AVIF jumps to 31.9 ms. WebP stays at 3.4 ms. The gap is 28.5 ms per image.
This is the single largest difference in the benchmark. The AV1 decoder costs more CPU than the WebP decoder, and that cost scales with CPU throttle.
Download time on the real CDN (lower is better)
Download time is the full round-trip: request sent until the last byte arrives. This runs on the production CDN path, not localhost.
| Network | Original (p50) | WebP (p50) | AVIF (p50) |
|---|---|---|---|
| Fast 4G | 265.8 ms | 193.2 ms | 190.9 ms |
| Slow 3G | 916.6 ms | 532.4 ms | 543.3 ms |
On fast 4G, AVIF and WebP are within 3 ms. On slow 3G, WebP is 11 ms faster. The download numbers are close because both formats produce similar file sizes for the same source.
Combined: download + decode
This table sums each image’s download median and decode median, then takes min / p50 / max across all 75 images. Slow 3G, mid-tier phone (4x CPU throttle).
| Format | Min (ms) | Median (ms) | Max (ms) |
|---|---|---|---|
| Original | 438 | 939 | 6,777 |
| WebP | 410 | 534 | 1,466 |
| AVIF | 413 | 547 | 1,406 |
WebP median is 534 ms. AVIF median is 547 ms. Both beat the original by a wide margin. WebP leads by 13 ms at the median.
On a low-end phone (6x), the gap widens because AVIF’s decode cost grows faster than WebP’s.
Low battery and thermal throttle
The 4x and 6x CPU rows simulate mid-tier and low-end phones. But they also represent something else: a flagship phone under stress.
- Apple’s Low Power Mode turns off 5G on most devices and caps CPU speed.
- Independent benchmarks show 30 to 40% lower CPU scores in this mode.
- Many Android battery-saver modes also cap the CPU clock.
- A hot phone throttles its CPU the same way (thermal throttling).
A flagship phone can temporarily perform like the 4x rows, on a slower network. The weak-CPU cells cover far more users than the low-end market share suggests. These cells are where WebP’s low decode cost wins by the widest margin.
Crossover model: break-even bandwidth
Experiment A produced a crossover model. For each image and CPU tier, we computed the bandwidth at which AVIF’s byte savings exactly offset its extra decode cost. Below that bandwidth, AVIF’s smaller file wins. Above it, the network is fast enough that decode cost dominates.
| Conversion | CPU tier | Median break-even (Mbps) |
|---|---|---|
| GIF to WebP | Desktop | 22.8 |
| GIF to WebP | Low-end | 5.8 |
| GIF to AVIF | Desktop | 36.9 |
| GIF to AVIF | Low-end | 9.5 |
| JPEG to WebP | Desktop | 37.6 |
| JPEG to WebP | Low-end | 5.8 |
| JPEG to AVIF | Desktop | 7.5 |
| JPEG to AVIF | Low-end | 1.8 |
| PNG to WebP | Desktop | 442.1 |
| PNG to WebP | Low-end | 391.7 |
| PNG to AVIF | Desktop | 100.7 |
| PNG to AVIF | Low-end | 24.9 |
WebP break-even bandwidths range from 5.8 to 442 Mbps. For most real networks, WebP always wins. AVIF break-even is lower (1.8 to 100 Mbps). On a fast network, AVIF’s decode cost can exceed its download savings.
PNG to WebP has the highest break-even (391 to 442 Mbps). PNG saves so many bytes that only an extremely fast network can make the decode cost matter.
Five criteria: the scorecard
Coverage (WebP wins). With a hard replacement and no fallback, each 1% gap is lost impressions. WebP at 97% loses 3%. AVIF at 95% loses 5%.
Decode cost (WebP wins). On low-end phones, AVIF takes 31.9 ms to decode. WebP takes 3.4 ms. That is a 9x difference.
Encode speed (WebP wins). For JPEG sources, WebP encodes in 14 ms (median). AVIF takes 340 ms. That is 24x slower. For GIF sources, the gap is 40x (45 ms vs 1,793 ms). The conversion service does not need extra machines for WebP.
Lossless mode (WebP wins). A separate test converted all 25 PNGs with pixel-identical lossless encoding. Every WebP file was smaller than its AVIF twin. The AVIF median was 1.27x larger.
Animation support (WebP wins). libvips writes animated WebP natively. Animated AVIF needs a special ffmpeg path because libvips cannot write HEIF sequence timing. See Part 01 for the full pitfall story.
Compression at equal quality (AVIF wins). AVIF has a higher compression ceiling. At the same SSIM, the AVIF file is smaller. But this advantage has a precondition: a fallback (like <picture>) must let the 5% of browsers without AVIF support fall back to WebP or the original. Without the fallback, the gap becomes lost users. This is why AVIF sits in M2.
What this means for the serving experience
The format with the best compression is not the format with the fastest paint. On the devices and networks that matter most for serving, decode cost cancels the compression advantage.
WebP wins because it balances all three axes: decent compression, low decode cost, and wide coverage. AVIF is the better format on paper. WebP is the better format for shipping today.
For how to ship it (quality settings, coverage gap, and the road to AVIF), see Part 03: Shipping WebP.
References:
- https://caniuse.com/webp (WebP browser support, 97%)
- https://caniuse.com/avif (AVIF browser support, 95%)
- https://support.apple.com/en-us/101604 (Apple Low Power Mode)
- https://developer.chrome.com/docs/devtools/device-mode#cpu (Chrome DevTools CPU throttle presets)
Related: Back to the benchmark overview or read Part 01: GIF to Animated WebP.