AVIF encoding is slow — here's why, and what to do about it
AVIF files are tiny, but encoding takes 5–10× longer than WebP. Understanding why helps you decide when the trade-off is worth it.
AVIF is the best image format for file size in 2026. A typical photo compressed to AVIF is 40–50% smaller than JPEG and 20–30% smaller than WebP at equivalent visual quality. But there's a catch: encoding is significantly slower.
How slow is it?
For a typical 1920 × 1080 photograph:
| Format | Encode time | File size | | -------- | ----------- | --------- | | JPEG q80 | ~20ms | 280 KB | | WebP q80 | ~60ms | 200 KB | | AVIF q80 | ~350ms | 140 KB |
AVIF encoding is roughly 6× slower than WebP and 17× slower than JPEG. For a single image, 350ms is barely noticeable. For a batch of 100 images in a build pipeline, the difference is 3.5 seconds vs 2 seconds vs 6 seconds — still manageable.
Why is AVIF slow?
AVIF uses the AV1 video codec for still images. AV1 was designed for video streaming, where encoding happens once and decoding happens millions of times. The codec was optimised for decode speed at the expense of encode speed.
The compression algorithm is also more complex:
- AV1 uses larger block sizes (up to 128×128 vs JPEG's 8×8)
- It has more prediction modes (67 intra modes vs JPEG's 9)
- Rate-distortion optimisation explores more combinations
- Multi-reference frame support adds computational overhead
When AVIF encoding speed matters
It doesn't matter for:
- Single image compression (350ms is imperceptible)
- Build-time processing (encode once, serve forever)
- CDN/edge processing (servers have fast CPUs)
- Browser-based tools like Tiny Pixel Kit (we're already optimised for it)
It matters for:
- Real-time image processing (user uploads, immediate response needed)
- Large batch processing (thousands of images)
- Low-power devices encoding many images
- Video frame extraction to still images
Speed vs size trade-off
The question isn't "is AVIF fast?" but "is the file size saving worth the encoding time?"
For a website serving 1 million page views per month with a 200 KB hero image:
| Format | File size | Monthly bandwidth | | ------ | --------- | ----------------- | | JPEG | 280 KB | 267 GB | | WebP | 200 KB | 191 GB | | AVIF | 140 KB | 133 GB |
Switching from JPEG to AVIF saves 134 GB per month of bandwidth. That's a significant CDN cost reduction, and every visitor gets a faster page load. The one-time encoding cost of 350ms per image is trivially worth it.
Speeding up AVIF encoding
If encoding speed is critical:
1. Lower the effort level
Most AVIF encoders have a speed/quality trade-off setting. In libaom, this is the "cpu-used" parameter (0–8, higher is faster). Default is usually 1–2; setting it to 4–6 dramatically speeds up encoding with minimal quality loss.
2. Use newer encoders
rav1e (Rust) and SVT-AV1 are significantly faster than libaom for encoding, with comparable quality. SVT-AV1 can be 3–5× faster at equivalent quality settings.
3. Encode in parallel
AVIF encoding is CPU-intensive but parallelisable. Use all available cores.
4. Skip AVIF for non-photographic content
Icons, logos and simple graphics see less benefit from AVIF. Use WebP or PNG for these — the file size difference is minimal, and encoding is instant.
Our recommendation
Use AVIF for photographs and complex images. Use WebP for everything else. The browser-based encoding in our tools handles the speed trade-off transparently — you just see a slightly longer progress bar for AVIF compared to WebP.