Everyone talks about how small AVIF files are. Almost nobody talks about what it costs to generate them in production. I run a free image converter built on Rust + libvips. After processing thousands of conversions, here are the numbers that changed how I think about format choice. The compression story you already know AVIF beats WebP on file size. For photos and gradients: AVIF saves ~50% vs JPEG (median across 600 photos) WebP saves ~31% vs JPEG At the same DSSIM score, AVIF produces files ~50% smaller than WebP Real and impressive. But that's only half the equation. The encoding cost nobody talks about Here's what actually happens when you encode with libaom (the default AVIF encoder): Format Encoding time (1080p) Peak CPU Peak RAM WebP ~90ms ~20% ~200MB AVIF (libaom, default settings) 1–4 seconds ~400% (4 cores) ~2.5GB AVIF (maximum quality) up to 48 seconds - - In my tests, AVIF encoding with libaom was up to 47× slower than WebP at comparable quality settings. Peak memory usage during a single 4000px AVIF conversion reached ~2.5GB in Sharp/libvips using libaom. WebP used ~200MB for the same image. The memory usage surprised me most. For a service handling concurrent batch uploads, that's not a benchmark number - it's a capacity planning problem. AVIF optimizes bandwidth. WebP optimizes compute. The effort parameter an oversimplification If you use Sharp, you've probably assumed: higher effort = smaller files. In practice, it's not that simple. quality is the primary driver of file size. effort controls how much time the encoder spends searching for better compression decisions. Depending on the image, higher effort can slightly reduce or even increase output size. The effect is unpredictable and usually marginal. This is documented behavior in Sharp's issue tracker (#3418): at fixed quality , increasing effort sometimes produces larger files. Practical starting point for AVIF in Sharp: sharp ( input ). avif ({ quality : 72 , effort : 5 }). toBuffer () effort: 5-6 hits a reasonable balance. Going to effort: 9 adds seconds of encoding for marginal and unpredictable gains. When to use which format Scenario Best format User uploads processed on-the-fly WebP Static assets, pre-generated at build AVIF Real-time transforms WebP Maximum compression for photos AVIF Low-memory servers WebP Screenshots, UI, flat graphics WebP Photography, gradients, textures AVIF The rule I follow: AVIF for static, WebP for dynamic. A 4-second encoding time is fine in a CI pipeline. It's not fine when a user is waiting for their converted file. What this looks like in a converter pipeline In my converter pipeline, the challenge with AVIF isn't throughput it's memory spikes under concurrent load. If multiple users upload large images simultaneously, AVIF jobs can spike memory hard across all cores. Current approach: Concurrency limits on AVIF jobs Default effort: 4 for interactive conversions fast enough for real-time use SVT-AV1 encoder is worth watching: roughly 2× faster than libaom, 5× faster than rav1e at comparable quality Browser support Effectively solved: WebP : ~95.6% global support (Safari 14+, all modern browsers) AVIF : ~94.3% global support (Safari 16.4+, Chrome 85+, Firefox 93+) The standard fallback pattern still makes sense: 
AVIF encoding speed — the numbers nobody talks about
Serhii Kalyna