Mean encoded size in KB on the horizontal axis against mean SSIM on the vertical, with the quality setting labelled at each point. Further left and higher up is better. Chart generated from the measurement run described below.
Mean encoded size in KB on the horizontal axis against mean SSIM on the vertical, with the quality setting labelled at each point. Further left and higher up is better. Chart generated from the measurement run described below.
Everyone has heard that AVIF is smaller and slower. The first half is measured here at 35 percent smaller across the whole curve. The second half did not survive the test: against WebP on its best compression setting, AVIF was the faster encoder.
There are two numbers in every codec argument and most guides only quote one of them. Everybody knows AVIF makes smaller files. The reason nobody uses it is the second number, encode time, and the received wisdom is that AVIF is far too slow to bother with for a gallery.
So this run measured both, on the same files, in the same process, with a stopwatch around the encoder.
Eight PNG files from this gallery, each capped at 1024 pixels on the long edge with Lanczos resampling. Every one is a PNG, so the reference has never been through a lossy pass and nothing is being scored against an already damaged original.
Each file was encoded three ways, JPEG with optimize on, WebP at method 6, and AVIF at speed 6, at quality 40, 50, 60, 70, 80 and 90. That is 144 encodes. Each result was decoded and scored with SSIM against the original on the luma channel, and the encode call itself was timed.
| Codec | Quality | Mean size | Mean SSIM | Mean encode |
|---|---|---|---|---|
| AVIF | 40 | 27.5 KB | 0.95445 | 0.314 s |
| AVIF | 50 | 39.8 KB | 0.96887 | 0.371 s |
| AVIF | 60 | 56.2 KB | 0.97751 | 0.412 s |
| AVIF | 70 | 77.3 KB | 0.98294 | 0.436 s |
| AVIF | 80 | 105.5 KB | 0.98730 | 0.427 s |
| AVIF | 90 | 159.9 KB | 0.99240 | 0.497 s |
| WebP | 40 | 41.0 KB | 0.95209 | 0.509 s |
| WebP | 50 | 46.6 KB | 0.95753 | 0.623 s |
| WebP | 60 | 52.5 KB | 0.96226 | 0.601 s |
| WebP | 70 | 59.1 KB | 0.96623 | 0.775 s |
| WebP | 80 | 76.0 KB | 0.97414 | 0.683 s |
| WebP | 90 | 128.8 KB | 0.98497 | 0.679 s |
| JPEG | 40 | 65.0 KB | 0.95254 | 0.022 s |
| JPEG | 50 | 74.8 KB | 0.95981 | 0.021 s |
| JPEG | 60 | 85.1 KB | 0.96550 | 0.021 s |
| JPEG | 70 | 100.9 KB | 0.97188 | 0.022 s |
| JPEG | 80 | 126.5 KB | 0.97894 | 0.027 s |
| JPEG | 90 | 187.1 KB | 0.98738 | 0.040 s |
The two bolded rows are the comparison that matters. AVIF at quality 60 produced a smaller file and a better score than WebP at quality 80. 56.2 KB against 76.0, and 0.97751 against 0.97414. Not a trade, a straight win on both axes.
Comparing quality numbers across codecs is meaningless, because quality 80 means a different thing in each encoder. The honest comparison holds the SSIM fixed and asks what it cost. Interpolating along each curve:
| Target | WebP | AVIF for the same score | JPEG for the same score |
|---|---|---|---|
| SSIM 0.95753 | 46.6 KB (q50) | 30.1 KB, 35.4% less | 71.7 KB, 53.9% more |
| SSIM 0.96226 | 52.5 KB (q60) | 34.2 KB, 34.9% less | 79.2 KB, 50.9% more |
| SSIM 0.96623 | 59.1 KB (q70) | 37.6 KB, 36.4% less | 86.9 KB, 47.0% more |
| SSIM 0.97414 | 76.0 KB (q80) | 49.8 KB, 34.5% less | 109.1 KB, 43.6% more |
| SSIM 0.98497 | 128.8 KB (q90) | 90.5 KB, 29.7% less | 169.9 KB, 31.9% more |
The saving is remarkably flat. Between SSIM 0.957 and 0.974 AVIF costs 34 to 36 percent fewer bytes than WebP at the identical score, every time. It narrows to 29.7 percent only at the top of the range, where every codec is spending bytes on detail nobody can see.
JPEG is the other end of the same ruler. At every matched score it costs 32 to 54 percent more than WebP, which is the reason the WebP advice everyone repeats was correct in the first place. It is just no longer the best available answer.
Here is the finding that changed the headline. Mean encode time per file across the six quality settings:
AVIF at speed 6: 0.41 seconds.
WebP at method 6: 0.65 seconds.
JPEG with optimize: 0.026 seconds.
AVIF was 36 percent faster than WebP on this run, at every quality level, without exception. The slowest AVIF encode in the table, 0.497 seconds at quality 90, is faster than the fastest WebP encode, 0.509 seconds at quality 40.
That result deserves a caveat rather than a victory lap, and the caveat is the settings. WebP method 6 is its slowest and most thorough mode, and AVIF speed 6 is a middle setting rather than its most thorough one. A gallery running WebP at method 4 would close most of that gap. What the numbers do rule out is the claim that AVIF is categorically too slow to consider, at least at the settings a real pipeline would use.
JPEG remains sixteen times faster than either of them and it is not close. If encode time genuinely is the constraint, that is the answer, and the price is roughly half again as many bytes.
If you are serving WebP at quality 80 today, which is the standard advice, AVIF at quality 60 is the direct replacement. Smaller file, higher score, faster encode. On a gallery of a thousand images that is roughly twenty megabytes of transfer per full crawl that stops existing.
Keep a WebP fallback in the picture element. AVIF support is wide now but it is not universal, and a fallback costs nothing but storage.
Do not push AVIF to quality 90 out of caution. It costs 159.9 KB for an SSIM of 0.99240 against 56.2 KB for 0.97751, which is nearly three times the bytes for a difference no viewer will find without a difference blend and a magnifier.
Eight files, eighteen encodes each, 144 files scored. Pillow 12 with libwebp at method 6, the built in AVIF encoder at speed 6, and JPEG with optimize enabled. SSIM computed on the luma channel with an 11 tap Gaussian window at sigma 1.5 and the standard stabilisers. Every original is a PNG, so there is no prior lossy pass to muddy the reference. Encode timings are wall clock around the save call on one machine with nothing else running, and they are indicative rather than a benchmark. The files are the ones in this gallery, which means the result describes AI art with soft backgrounds and sharp faces, and might not hold for a page full of screenshots or line art.