AVIF vs WebP: Which Format Should You Serve First?

This question sits underneath the broader workflow in serving AVIF and WebP with fallbacks, part of the Image & Media Optimization discipline: once you have decided to ship modern codecs behind a fallback chain, which one earns the top <source> slot — the one the browser reaches for first? The honest answer is that there is no single winner; the right primary codec depends on the content class, the device tier you are optimizing for, and whether the image lands on the Largest Contentful Paint critical path. This page replaces "always AVIF" with a decision you can defend per image.

Rapid Diagnosis: Which Axis Actually Decides It

Before reaching for a matrix, narrow the decision with a four-question DevTools checklist on the specific image in question. First, is it the LCP element? Open the Performance panel, throttle CPU 6x, and find the Decode Image task — if the image is the LCP candidate and decode is a large slice of render delay, decode cost outweighs raw byte savings. Second, what content class is it? Photographic continuous-tone images favor AVIF; flat illustrations, screenshots, and text-bearing graphics expose AVIF banding earlier and narrow its lead. Third, how small is it? Below a few KB, AVIF's container overhead can make it larger than WebP — check actual transferred bytes, not the assumption. Fourth, does it need alpha or animation? Both support alpha; neither is a good animation choice. Those four answers usually decide the format before you ever consult the table.

The 2026 Decision Matrix

The trade-offs cluster along seven axes. AVIF generally wins on raw compression and HDR; WebP wins on encode speed, decode cost, and small-image overhead; support is effectively universal for both among current browsers.

A few cells deserve the caveat that a single word in a table cannot carry. The compression edge for AVIF is largest on noisy, detailed photography and shrinks toward parity on flat or low-frequency images. The support row reads "universal" for both because legacy-browser share is now negligible, but WebP's longer history means a slightly deeper tail of old clients decode it — which only matters if your fallback <img> is missing, and it never should be. And the animation row is a warning, not a comparison: when you reach for animated AVIF or WebP, stop and reach for a muted playsinline <video> instead, which beats both on bytes and decode.

Root Cause Analysis: Why the "Always AVIF" Reflex Misfires

Three named failure modes explain why defaulting every image to AVIF backfires in production.

1. Decode-bound LCP regression. AVIF decode is CPU-heavy, and the LCP element must be decoded before it can paint — decoding="async" cannot move that work off the critical path for the element that defines the metric. On a low-end phone a full-bleed AVIF hero can spend 30–80ms decoding, landing inside the LCP render-delay phase. The mechanism: you shaved 80KB off transfer but added 60ms of decode, and on a fast-but-throttled-CPU device the WebP variant paints sooner despite being larger. The byte chart shows a win; the LCP timestamp shows a loss.

2. Small-image overhead inversion. AVIF's container and per-tile metadata impose a fixed overhead that is invisible on a 1200px hero but dominates on a 48px icon or a 4KB thumbnail. The mechanism: below the overhead break-even point, the AVIF is larger than the WebP or even an optimized PNG, so an "optimize everything to AVIF" build step quietly inflates your smallest, most numerous assets.

3. Flat-content banding. AVIF's aggressive quantization at low cq-level introduces visible banding in smooth gradients and ringing around hard edges — sunsets, UI chrome, charts, text screenshots. The mechanism: to hide the banding you must raise quality, which erodes the byte lead until WebP at a comparable perceptual score is competitive, with cheaper decode as a bonus.

Step-by-Step Resolution: Picking and Ordering the Codec

Apply these fixes in order of impact. Each assumes you already ship a fallback <img> floor as described in the parent guide.

1. Default photographic content to AVIF-first, WebP-second. For continuous-tone photos above the small-image threshold, order AVIF before WebP in the <picture> chain so supporting browsers take the smallest file.

<picture>
  <source type="image/avif" srcset="photo-1200.avif 1200w" sizes="1100px">
  <source type="image/webp" srcset="photo-1200.webp 1200w" sizes="1100px">
  <img src="photo-1200.jpg" width="1200" height="800" alt="Coastline at dusk"
       decoding="async">
</picture>
<!-- trade-off: AVIF-first assumes decode is not on the critical path. For the LCP
     hero on a low-end-device audience, profile decode first; WebP-first can paint
     sooner there despite shipping more bytes. -->

Expected outcome: reduces transfer of supported clients by ~40–50% versus JPEG on detailed photos, with no LCP penalty for below-the-fold images.

2. Promote WebP-first for the LCP image on low-end audiences. When the Performance panel shows AVIF decode dominating render delay on your target device, flip the order so WebP wins on supporting clients and reserve AVIF for the byte-sensitive, CPU-rich case only if at all.

<picture>
  <source type="image/webp" srcset="hero-1200.webp 1200w" sizes="1100px">
  <img src="hero-1200.jpg" width="1200" height="675" alt="Dashboard hero"
       fetchpriority="high" decoding="async">
</picture>
<!-- trade-off: dropping the AVIF source forfeits ~10-15% more bytes. Only do this
     when decode time measurably outweighs the byte saving on the LCP element for
     your real device distribution. -->

Expected outcome: removes ~30–60ms of main-thread decode from the LCP render-delay phase on low-end devices, typically reducing LCP by that margin.

3. Size-gate AVIF so small assets stay WebP. In the build, skip AVIF below a byte threshold where its overhead inverts the win, emitting WebP-only variants for icons and thumbnails.

// emit AVIF only above the overhead break-even; WebP for everything small
import sharp from 'sharp';
const meta = await sharp(src).metadata();
const big = meta.width >= 400;            // small assets: WebP only
await sharp(src).webp({ quality: 80 }).toFile(out + '.webp');
if (big) await sharp(src).avif({ quality: 50 }).toFile(out + '.avif');
// trade-off: the 400px gate is a heuristic, not a law. Verify break-even per asset
// class — a noisy 300px photo may still favor AVIF, a flat 600px chart may not.

Expected outcome: prevents AVIF overhead from inflating small assets, often cutting a few KB per icon across hundreds of entries.

4. Force AVIF 4:4:4 (or stay WebP) for text and sharp-edged graphics. For screenshots, charts, and colored text, default chroma subsampling smears edges; use full chroma or keep WebP.

avifenc --yuv 444 -a cq-level=24 chart-master.png chart.avif
# trade-off: 4:4:4 raises bytes notably. Use it only for sharp/colored detail;
# leave photographic content at the default 4:2:0 where the eye can't see chroma.

Expected outcome: eliminates color fringing on text/UI at the cost of a larger file, keeping the asset legible where 4:2:0 would visibly degrade it.

Verification

Confirm the choice with a before/after diff on the specific image, not the average. Capture transferred bytes in the Network panel and the Decode Image task in the Performance panel for both the old and new codec, then check the net effect on the LCP timestamp under your target CPU throttle. The win condition is unambiguous: fewer bytes and equal-or-earlier paint. If bytes drop but LCP rises, the decode tax exceeded the transfer saving and you chose wrong for that image.

Lock the decision in CI. Assert Lighthouse's modern-image-formats so no asset silently reverts to legacy JPEG/PNG, and pair it with a hard LCP budget so a decode-bound regression cannot pass on byte size alone. For field confirmation, watch p75 LCP in your RUM data after the change — real-device decode cost shows up in field numbers that a fast lab machine hides.

{
  "ci": {
    "assert": {
      "assertions": {
        "modern-image-formats": ["error", { "minScore": 1 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }]
      }
    }
  }
}

When to Pick Which

Reduce it to four rules. Pick AVIF-first for above-the-fold and below-the-fold photographic content where decode is not the binding constraint — it is the byte winner there. Pick WebP-first (or WebP-only) for the LCP image when your audience skews low-end and the Performance panel shows decode dominating render delay. Pick WebP for small assets (icons, thumbnails) where AVIF overhead inverts the saving, and for flat illustrations/charts where banding erodes the lead — using AVIF 4:4:4 only when sharp colored detail demands it. And pick neither for animation: serve a muted playsinline <video>. In every case, ship the JPEG/PNG <img> floor underneath so the decision is purely an optimization, never a compatibility risk.

Related

• Serving AVIF and WebP with fallbacks — the full encoding, negotiation, and fallback-chain workflow this decision plugs into.
• Responsive images with srcset and sizes — pair the codec choice with a resolution ladder so each source serves the right size too.
• Image CDNs and fetchpriority — let a CDN transcode per Accept header and ensure the chosen file fetches at high priority.
• Measuring LCP with Chrome DevTools — verify that the codec decision moved the loading metric on real device profiles.
• Image & Media Optimization — the broader media-weight strategy behind the format decision.