WebP vs AVIF nel 2026: Quale Usare per il Tuo Sito
Confronto onesto 2026: WebP vs AVIF per performance web, supporto browser, dimensione file, velocità di codifica e la catena di fallback pratica, con benchmark reali.
WebP è uscito nel 2010. AVIF è uscito nel 2019. Nel 2026, entrambi sono maturi, entrambi hanno supporto browser globale di ~94%+, ed entrambi schiacciano JPG/PNG sulla dimensione del file. Ma scegliere tra loro, o come usare entrambi, fa ancora inciampare sviluppatori e content manager. Questa guida ti dà benchmark reali e una regola di decisione pulita.
TL;DR, la risposta 2026
Per siti statici e asset pre-costruiti: AVIF prima, fallback WebP, JPG/PNG ultimo. Il tag <picture> gestisce automaticamente la catena.
<picture>
<source srcset="/img/photo.avif" type="image/avif" />
<source srcset="/img/photo.webp" type="image/webp" />
<img src="/img/photo.jpg" alt="…" />
</picture>Per ridimensionamento dinamico, generazione real-time o budget CPU vincolati: solo WebP. La codifica AVIF è troppo pesante al request time.
La decisione in una frase
Se l'immagine è generata una volta e servita per sempre, usa AVIF + fallback WebP. Se è generata per richiesta, usa solo WebP.
Benchmark reali: stessa sorgente, entrambi i formati
10 foto rappresentative compresse a qualità “visivamente lossless” (SSIM ≥ 0.99 vs originale):
| Sorgente (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Foto spiaggia (cielo gradiente) | 2.4 MB | 1.3 MB | 0.7 MB | −71% |
| Ritratto (toni pelle) | 1.8 MB | 0.9 MB | 0.55 MB | −69% |
| Prodotto su sfondo bianco | 1.1 MB | 0.45 MB | 0.28 MB | −75% |
| Cityscape (alto dettaglio) | 3.2 MB | 1.8 MB | 1.1 MB | −66% |
| Fotografia cibo | 2.1 MB | 1.0 MB | 0.62 MB | −70% |
| Paesaggio con texture | 2.7 MB | 1.6 MB | 1.0 MB | −63% |
| Logo / illustrazione | 380 KB | 120 KB | 95 KB | −75% |
| Screenshot (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Moda (alto contrasto) | 1.9 MB | 0.95 MB | 0.58 MB | −69% |
| Macro / dettaglio natura | 2.5 MB | 1.4 MB | 0.85 MB | −66% |
| Media | 1.86 MB | 0.97 MB | 0.61 MB | −70% |
Per un’immagine tipica, AVIF risparmia ~70% su JPG, ~37% su WebP. I risparmi sono massicci su scala: 100 foto = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Reality check supporto browser
| Browser | WebP | AVIF | Quota di mercato (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | Ago 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Ott 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mar 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Vecchio IE / IE Mode | Mai | Mai | <1% |
| Supporto combinato | ~99% | ~94% | n/a |
Il gap del 6% AVIF
Il 6% senza AVIF è per lo più: (a) Android < 7 ancora in uso in alcune regioni, (b) vecchi holdout aziendali Edge/IE, (c) WebView embedded in app più vecchie. Spedisci sempre un fallback WebP, copre tutti loro.
Velocità di codifica: il vantaggio WebP
La compressione AVIF è più pesante perché il codec è più complesso (derivato da HEVC). Su un carico di lavoro tipico:
| Operazione | WebP (libwebp) | AVIF (libaom) | Differenza |
|---|---|---|---|
| Foto 4 MP → q80 | 0.8s | 4.2s | 5× più lento |
| Foto 4 MP → q60 | 0.6s | 3.5s | 5.8× più lento |
| Foto 12 MP → q80 | 2.1s | 12s | 5.7× più lento |
| 100 miniature (300×300) | 8s | 38s | 4.7× più lento |
| Build intera libreria immagini (1000 imgs) | 14 min | 1h 12min | 5.1× più lento |
Per build di siti statici questo va bene, codifica una volta, servi per sempre. Per ridimensionamento dinamico (es. utenti che caricano avatar al request time), il costo 5× è proibitivo.
Quando scegliere WebP
Scegli solo WebP quando
- Generi immagini al request time (ridimensionamento dinamico)
- CPU/tempo di build sono vincolati
- Vuoi tooling più semplice (supporto libreria più ampio)
- Il tuo CDN non supporta ancora AVIF
- Il tuo pubblico tende molto Android-vecchio (regioni con dispositivi vecchi)
Scegli AVIF + fallback WebP quando
- Sito statico con asset pre-costruiti
- Sito ricco di foto (e-commerce, portfolio, news)
- I costi di larghezza di banda contano (bollette CDN, utenti mobile)
- I Core Web Vitals sono critici (il peso delle immagini è il tuo collo di bottiglia)
- Puoi risparmiare CPU al build time
La catena di fallback in pratica
L’elemento HTML <picture> è il modo standard per spedire formati multipli. Il browser sceglie il primo formato che capisce.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Immagine hero" loading="lazy" />
</picture>I framework moderni generano questo automaticamente:
| Framework | Come |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + config images.formats |
| Gatsby | gatsby-plugin-image con formats |
| Vite | Plugin vite-imagetools |
| Nuxt | @nuxt/image con array format |
| Hugo | Page resources + Resize + Convert |
Non spedire AVIF senza WebP
Il 6% di utenti senza supporto AVIF non vedono un'"immagine rotta", vedono niente. Il tag <picture> ricade sull'<img> se tutte le voci <source> falliscono. Includi sempre WebP (o JPG) come rete di sicurezza.
Mappatura della manopola di qualità
Il numero che metti in q= per AVIF non si mappa a JPG/WebP. Equivalenti approssimativi:
| Qualità visiva | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Quasi lossless | 95 | 95 | 80 |
| Visivamente lossless | 90 | 85 | 65 |
| Nitido a visualizzazione normale | 85 | 80 | 60 |
| Accettabile | 75 | 70 | 50 |
| Compressione visibile | 60 | 55 | 35 |
| Artefatti pesanti | 40 | 35 | 20 |
Default per web: JPG 85, WebP 80, AVIF 60, tutti producono output visivamente identico.
Tip di codifica per i migliori risultati
- Codifica sempre dall’originale (non da un JPG → ricodificato WebP), o accumuli perdite.
- Per le foto, usa q60 AVIF / q80 WebP, il sweet spot.
- Per grafica con bordi nitidi, passa a WebP lossless o fallback PNG. AVIF lossy può sfocare linee fini.
- Non preoccuparti di AVIF per miniature sotto 100×100, la differenza di dimensione del file è minuscola rispetto al costo di codifica.
- Rimuovi i metadati (EXIF, ICC) quando possibile, risparmi altri 10-30 KB per immagine.
E JPEG XL?
JPEG XL (JXL) è un formato più nuovo che alcuni hanno chiamato “AVIF killer” nel 2022. Nel 2026:
- Chrome ha rimosso il supporto nel 2023 (decisione controversa).
- Safari lo supporta (dal iOS 17).
- Firefox: dietro un flag.
Non vale ancora la pena distribuirlo in produzione. La storia del supporto browser è troppo incerta. Rivisita nel 2027.
Riepilogo
Per il 90% dei siti web nel 2026:
- La pipeline di build codifica ogni immagine in AVIF + WebP + JPG/PNG.
- Il tag
<picture>in HTML serve quello giusto in base al browser. - JPG qualità 85, WebP 80, AVIF 60 come default, visivamente identici.
- Salta AVIF solo per immagini minuscole o percorsi di generazione dinamica.
- Misura con Core Web Vitals prima e dopo, il peso delle immagini dovrebbe scendere ~70%.
Puoi convertire i tuoi asset esistenti proprio adesso con JPG in WebP, PNG in WebP, o elaborare in batch via Converti Immagine. Tutto gira localmente, nessun caricamento, nessun server.