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):

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

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:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

The actual takeaway

"Better compression" and "better for your use case" aren't the same thing.

AVIF is technically superior for compression. But if you're encoding on-the-fly, the encoding overhead is a real operational cost not a benchmark footnote.

WebP is fast, lightweight, and produces files dramatically smaller than JPEG. It's not a consolation prize.

The best setup: pre-generate AVIF for static assets, encode WebP dynamically, serve both via <picture> or CDN content negotiation.

Building Convertify a free image converter powered by Rust + libvips. Week 9 of building in public.

Sources: Sharp GitHub issues #2597, #3418 · libheif AVIF Encoder Benchmark · SpeedVitals WebP vs AVIF · W3Techs image format statistics (May 2026) · Can I Use