AVIF vs WebP for Magento: measure your own catalog

Lead

Every article about modern image formats quotes the same headline: WebP is "25-35% smaller than JPEG," AVIF is "smaller still." Both are true and both are useless for a decision, because the only number that matters is what your catalog does. A store full of clean studio product shots on white compresses very differently from one full of lifestyle photography, flat PNG diagrams, or text-heavy banners.

So this isn’t an AVIF vs WebP "which format wins" article. AVIF usually produces the smallest files; that part isn’t in dispute. This is about measuring the savings on your own media, weighing them against encode cost, and deciding where each format earns its place.

Why now

AVIF browser support is effectively universal in 2026, so the historical reason to stay on WebP — "AVIF fallback is risky" — has mostly evaporated. The remaining question isn’t can you ship AVIF, it’s should you ship it everywhere, given it costs more CPU to encode and the per-image savings vary wildly. That’s a measurement question, and it’s worth answering before you turn AVIF on across a 200,000-image catalog.

Baseline

Out of the box Magento serves whatever you uploaded — usually JPEG for photography, PNG for anything with transparency or sharp edges. The optimizer adds two converters: module-image-optimizer-webp and module-image-optimizer-avif, each writing a sidecar next to the original at a configurable quality. Quality is set per format — WebP and AVIF each have their own field under Stores → Configuration → Services → BroCode ImageOptimizer, both defaulting to 80.

The decision you’re actually making is per image class, not per store: photography, flat graphics, and banners each behave differently in any AVIF vs WebP comparison, and a single global quality setting hides that.

Tradeoffs

AVIF vs WebP is a trade-off, not a winner. Frame it as a table, not a verdict.

AVIF

• Strength: typically the smallest files on photographic content with smooth gradients.
• Cost: slowest to encode — meaningfully more CPU per image, which matters at catalog scale and pushes you toward async conversion.

WebP

• Strength: fast to encode, near-universal support including older clients, and — on flat PNG graphics — better compression than AVIF at per-image scale (see the results below).
• Cost: larger than AVIF on most photographic content; leaves savings on the table there.

The practical answer for most stores is both: serve AVIF where it wins, WebP as the broad fallback, originals last. The content-negotiation setup that makes that automatic is covered in the nginx article (see Related reading).

Working example: measure it

Run both converters at matched quality on a representative slice of pub/media — not one hand-picked image — and tabulate the results. Pick a few hundred images that mirror your real mix: product shots, category PNGs, a few banners.

If PHP isn’t available (or you want to convert independently of the module), avifenc handles the sidecar generation directly. The flag syntax depends on the installed version — check with avifenc --version:

# avifenc v1.0+: -q 0–100 (higher = better quality)
find pub/media/catalog -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) \
  | xargs -P4 -I{} sh -c 'avifenc -q 60 "$1" "${1}.avif"' _ {}

# avifenc <v1.0: --min/--max 0–63 (lower = better quality)
find pub/media/catalog -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) \
  | xargs -P4 -I{} sh -c 'avifenc --min 20 --max 40 "$1" "${1}.avif"' _ {}

-P4 runs four parallel encodes — scale to the number of available cores. avifenc does not preserve the source file’s mtime; the sidecar gets the current timestamp. The Magento module tracks conversions by file existence, not mtime, so this is safe. If you need timestamps matched for other reasons, append && touch -r "$1" "${1}.avif" inside the shell command.

Install via apt install libavif-apps (Debian/Ubuntu) or yum install libavif-tools (RHEL/Amazon Linux). Confirm AVIF support in ImageMagick as a fallback with convert -list format | grep AVIF.

For WebP sidecars, cwebp uses a consistent -q 0–100 flag across all versions (no version split needed), with output specified via -o:

find pub/media/catalog -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) \
  | xargs -P4 -I{} sh -c 'cwebp -q 80 "$1" -o "${1}.webp"' _ {}

-q 80 matches the module’s default quality. Same mtime behaviour as avifenc — append && touch -r "$1" "${1}.webp" if you need timestamps preserved. Install via apt install webp (Debian/Ubuntu) or yum install libwebp-tools (RHEL/Amazon Linux).

A minimal measurement loop over a sample directory:

SCAN_DIR="pub/media/catalog/product/cache"

if stat -c '%s' /dev/null >/dev/null 2>&1; then
    filesize() { stat -c '%s' "$1"; }
else
    filesize() { stat -f '%z' "$1"; }
fi

for ext in jpg jpeg png webp avif; do
  total=0; count=0
  while IFS= read -r f; do
    size=$(filesize "$f")
    total=$((total + size)); count=$((count + 1))
  done < <(find "$SCAN_DIR" -type f -iname "*.${ext}")
  printf '%-6s %12d bytes  (%d files)\n' "$ext" "$total" "$count"
done

Then compute the percentage each modern format saves against the originals it was generated from. Encode time matters too — wrap the conversion run in time (or read it off the queue) so the CPU cost is visible alongside the savings.

Two measurements on the same catalog, each telling a different part of the AVIF vs WebP story.

Count-weighted sample (n = 2,000 per class, random, files with both sidecars)

Each image contributes equally regardless of size — representative of the typical image, not the typical byte.

Image class	Original (avg)	WebP (avg)	AVIF (avg)	WebP saving	AVIF saving
JPEG product images	8,789 B	5,472 B	3,536 B	−47.6% (5σ CI: 46.0–49.2%)	−52.9% (5σ CI: 51.9–53.9%)
PNG graphics / overlays	62,829 B	6,260 B	5,589 B	−80.7% (5σ CI: 79.4–82.0%)	−72.6% (5σ CI: 69.7–75.4%)

Byte-weighted full scan (per class, all files with matching sidecars)

Every byte contributes equally — representative of total transfer volume, dominated by larger files.

Image class	Originals	WebP	AVIF	WebP saving	AVIF saving
JPEG product images (186,329 files)	1,812 MB	1,119 MB	706 MB	−38%	−61%
PNG graphics / overlays (26,655 files)	1,515 MB	148 MB	139 MB	−90%	−91%
Combined	3,327 MB	1,267 MB	845 MB	−61.9%	−74.6%

The count-weighted sample predicted AVIF’s overall byte-weighted saving at ~62% — the actual byte-weighted scan shows −74.6%. That 12.7pp gap is explained by the per-class breakdown: AVIF’s JPEG advantage is far larger at byte scale than a per-image sample suggests, because large product shots (where AVIF excels most) dominate transfer volume.

The per-class numbers also reveal two surprises. For JPEG, the byte-weighted AVIF advantage is 23pp (−61% vs −38%), much wider than the count-weighted sample showed (−52.9% vs −47.6%). For PNG, both formats hit ~90% — essentially equivalent. The count-weighted sample suggested WebP was ahead on PNG (−80.7% vs −72.6%), but that difference disappears when larger PNG files dominate the byte count.

Read the AVIF vs WebP results by class and by metric. For JPEGs, AVIF’s byte-weighted saving is more than 1.6× WebP’s — the gap is too large to ignore. For PNG graphics, both codecs are equivalent; the encode cost of AVIF buys nothing extra there.

What to skip

• Don’t chase AVIF on tiny assets. Icons and sprites save bytes you can’t measure; the encode cost and sidecar clutter aren’t worth it.
• Don’t benchmark a single cherry-picked image. One hero shot tells you nothing about an AVIF vs WebP comparison at catalog scale. Sample across classes.
• Don’t crank quality to 100 "to be safe." You’ll erase most of the savings. Test a couple of quality levels and look at the size/quality curve, not the extremes.

Verification

Confirm the converter actually produced what you think, and at the size you expect:

ls -la photo.jpg photo.jpg.webp photo.jpg.avif

curl -sI -H 'Accept: image/avif,image/webp,*/*' \
  https://your-store/media/catalog/product/x/y/photo.jpg \
  | grep -iE 'content-type|content-length'

The Content-Length on the negotiated response should match the AVIF sidecar’s size — proof the savings reach the browser, not just the disk.

Related reading

• BroCode Image Optimizer — the converters used here
• No template changes: serving WebP and AVIF with nginx
• Rolling out AVIF on a live store without breaking your CDN
• Async image optimization with the Magento queue