AVIF Encoding Time vs File Size: When Slow Compression Pays Off

AVIF ships files 20-50% smaller than WebP but encodes up to 100x slower than JPEG at high effort. Encode once and serve it millions of times, the wait is free. Convert per request without a cache, and that wait becomes your latency bill.

I test this the way I test a checkout flow: against a baseline, with a stopwatch and a byte counter. AVIF encoding time vs file size is not a philosophy question. It is a measured curve, and you decide where on the curve you want to sit.

What is AVIF and why is it so slow to encode?

AVIF is a still-image format built on the AV1 video codec, so every image you encode runs through an intra-frame video compressor doing block partitioning, transform search, and rate-distortion optimization. JPEG does a fraction of that work. That extra search is exactly where the file-size wins come from, and exactly why the clock runs longer.

The key knob is the encoder "effort" or "speed" setting. In libaom (cpu-used) and sharp's effort option (0-9), a low speed number means the encoder searches harder, finds a smaller file, and takes much longer. A single 2000px photo can go from roughly 0.4 seconds at low effort to 12-20 seconds at max effort on a normal server core. The file might only shrink another 8-15% for that 30x time cost. The curve flattens fast.

The mistake I see most: teams pick effort 9 "to be safe," then wonder why their image build takes 40 minutes. The last two effort steps buy single-digit percentage savings for double-digit time multipliers.

How much smaller is AVIF than JPEG and WebP, really?

AVIF typically lands 20-30% smaller than WebP and 40-50% smaller than a quality-matched JPEG for photographic content. Netflix's early AV1 image tests and Jake Archibald's detailed AVIF comparison both show AVIF holding detail at bitrates where JPEG falls apart into blocking. The gains are largest on photos and gradients, smallest on flat graphics and text where PNG or WebP-lossless can match it (see PNG vs JPG vs WebP).

Here is the shape of the trade on a typical 1920px hero photo, quality tuned to look identical:

Format	File size	Encode time (1 core)	Notes
JPEG q80	210 KB	0.05 s	Universal, fastest
WebP q80	150 KB	0.3 s	~28% under JPEG
AVIF effort 4	105 KB	1.5 s	Best size-per-second for most builds
AVIF effort 9	95 KB	14 s	~10% smaller than effort 4, ~9x slower

The jump from JPEG to AVIF effort 4 is the money move: roughly half the bytes for a couple of seconds. The jump from effort 4 to effort 9 is where people quietly burn their afternoon.

When does batch AVIF encoding make sense?

Batch encoding makes sense whenever an image is encoded far fewer times than it is served. This is almost every static asset on the web: product photos, blog heroes, marketing pages, avatars once uploaded. You pay the encode cost once, at build time or on upload, and every visitor for the next year downloads the small file.

Good fits for slow, high-effort batch AVIF:

• Static site and CMS builds where images are processed at deploy, not per request.
• Upload pipelines that convert asynchronously in a queue after the user uploads, so the user is never blocked on the 12-second encode.
• CDN or storage-backed asset libraries served millions of times, where a 10% extra byte saving compounds across huge traffic.
• Anything cached hard with long Cache-Control and content hashing (see long Cache-Control and content hashing).

In all of these, spend the effort. Run effort 6-9 in a background job. Nobody is waiting on it, and the byte savings are permanent. This is exactly the model behind Pixel Wand: convert once with SSIM-driven quality so the smallest visually-identical file gets served every time after.

When should you avoid on-the-fly AVIF conversion?

Avoid per-request AVIF conversion any time a user is waiting on the response and the result is not cached. On-the-fly encoding puts a 1-15 second CPU-bound task directly in your request latency, and AV1 encoding will saturate cores fast. Ten concurrent conversions at effort 6 can pin a server and turn a fast page into a timeout.

Specific traps:

• Image proxy/resize services without a cache re-encoding the same asset on every hit. That is pure waste and a latency spike per user.
• Serverless functions billed by execution time, where a 10-second AVIF encode is a 10-second invoice, repeated.
• First-view cold caches where the very first visitor eats the full encode as page latency. Each extra second of load costs roughly 4% of conversions, so a 12-second stall is not a rounding error, it is the whole funnel.

If you must convert near request time, cap effort at 2-4, always write the result to a persistent cache so it happens exactly once per asset, and serve the cached copy forever after. Never let the same image encode twice.

How do I pick the right AVIF effort level?

Pick the lowest effort that gets you within a few percent of the best size, then stop. For most photographic web content that is effort 4-6. Test on your own images because content matters: noisy photos and film grain compress differently than clean studio shots.

A quick way to find your line:

1. Take 10-15 representative images, not one lucky sample. Include a busy photo, a flat graphic, a screenshot, a gradient.
2. Encode each at effort 2, 4, 6, and 9. Record bytes and wall-clock time for each.
3. Plot size against time. The point where the size curve goes nearly flat is your setting.
4. Confirm visual quality with a structural metric like SSIM, not just your eyes at 100% zoom (see SSIM).

The web.dev guide on serving modern image formats is a solid reference for wiring the <picture> fallback so browsers that lack AVIF still get WebP or JPEG. Serve AVIF first, WebP second, JPEG last. That way slow encoding never becomes a compatibility problem.

Does AVIF decode slowly too, or just encode?

Encoding is the slow half. Decoding AVIF is more expensive than JPEG for the browser but is measured in milliseconds, not seconds, and modern browsers handle it fine for typical image sizes. The asymmetry is the good news: you pay the big cost once at encode time, and every visitor gets cheap decoding plus a much smaller download. The download savings almost always dominate the slightly higher decode cost on real networks.

The one caution is very large images, like 6000px-plus panoramas, where AVIF decode can cause a visible hitch on low-end phones. For those, test on a real mid-range device before committing.

---

FAQ

Is AVIF always smaller than WebP?

No. AVIF wins clearly on photos and gradients, usually by 20-30%. On flat graphics, logos, and images with sharp text, WebP-lossless or PNG can tie or beat it. Test per image type rather than assuming one format wins everywhere.

What AVIF effort setting should I use for a website?

Effort 4-6 for most photographic content. It captures nearly all the file-size benefit of the highest settings while encoding several times faster. Reserve effort 8-9 for offline batch jobs on high-traffic assets where the extra 5-10% saving compounds.

Can I convert images to AVIF on the fly for every request?

Only if you cache the result so each asset encodes exactly once. Uncached per-request AVIF encoding puts a multi-second CPU task in your response path and will spike latency and CPU under load. Convert once, cache hard, serve the small file forever.

Start by running your ten most-viewed images through effort 2, 4, 6, and 9, then plot bytes against seconds. The point where the size line flattens is the effort level your whole pipeline should use, and you will usually find it sitting lower than you expected.

---

Find any asset in seconds. Photo Atlas is digital asset management for creative and brand teams, with early-access founder pricing for the first users. Get early access