AVIF vs WebP vs JPEG: compressione misurata e quale scegliere

Ultimo aggiornamento: 25 luglio 2026

WebP è il formato predefinito per la maggior parte delle immagini web: nei miei test è del 56–64% più piccolo di JPEG e viene renderizzato in tutti i browser attuali. AVIF comprime ancora di più — 81–89% più piccolo di JPEG — ma codifica circa 2–3× più lentamente. Mantieni JPEG solo per email e sistemi legacy. I numeri qui sotto provengono da un vero benchmark su quattro immagini che ho eseguito, non dalle affermazioni riciclate del tipo "AVIF è più piccolo del 50%" che ogni guida ai formati copia dagli altri.

Risposta rapida: AVIF, WebP o JPEG?

Scegli il formato più piccolo che il tuo pubblico riesca a visualizzare. Per la maggior parte dei siti ciò significa prima AVIF, poi WebP come fallback, infine JPEG. Ho misurato tutti e tre su quattro tipi di immagine a qualità equiparata, e AVIF ha vinto in ogni categoria sulle dimensioni del file — ma WebP ha codificato in un terzo del tempo.

Se servi un solo formato, scegli WebP — gira su tutti i browser attuali e risparmia oltre la metà dei byte. Se puoi servire più formati tramite <picture>, guida con AVIF per le fotografie. Il Convertitore di immagini e il Compressore di immagini esportano tutti e tre a partire da un'unica immagine sorgente.

Perché la diffusa affermazione "AVIF è più piccolo del 50%" la sottovaluta

La maggior parte delle guide ai formati ripete gli stessi tre numeri — "AVIF ~50% più piccolo di JPEG", "AVIF ~20% più piccolo di WebP", "WebP 25–34% più piccolo di JPEG" — e tutti risalgono a uno o due studi dei fornitori che tutti si citano in cerchio. Il mio benchmark racconta una storia diversa: contro JPEG q80 a qualità equiparata, AVIF è risultato 81–89% più piccolo, non del 50%. WebP è risultato 56–64% più piccolo, non del 25–34%.

Il divario conta perché i risparmi reali generano veri miglioramenti nei Core Web Vitals. Se una guida ti dice che WebP risparmia "25–34%" e pianifichi la larghezza di banda su quella base, sottostimi della metà. Ho eseguito il benchmark sulle quattro immagini con gli encoder libaom (AVIF), libwebp e mozjpeg di sharp a effort 4, e la tabella sopra è l'output grezzo — riproducilo sulle tue immagini prima di fidarti di qualsiasi percentuale, compresa la mia.

Il file AVIF più piccolo è davvero bello come sembra?

Sì, per le fotografie, nel giusto intervallo di qualità. Il motivo per cui "AVIF è più piccolo" non è tutta la storia è che ogni formato si rompe in modo diverso quando spingi la qualità troppo in basso. A impostazioni sensate le differenze svaniscono alla normale distanza di visualizzazione.

Le modalità di fallimento sono specifiche del formato e ti dicono dove ciascun formato cede:

La lezione pratica: mantieni AVIF nell'intervallo di qualità 60–70 per le fotografie. Sotto circa 30, AVIF sfuma il dettaglio in un modo che risulta "sbagliato" più velocemente del ringing di un JPEG più grande — l'occhio tollera meglio gli artefatti di JPEG rispetto alla texture mancante.

Il compromesso sul tempo di codifica che nessuno valuta

Ogni guida ai formati afferma "AVIF è più lento da codificare" e passa oltre. Nessuna di quelle che ho trovato traccia il vero compromesso. Ho misurato il tempo di codifica AVIF lungo il cursore di effort sulla stessa foto ritratto a qualità 65, e la curva non è quella che assumeresti:

Effort 4 è il punto ottimale — file più piccolo (9.8 KB) a un tollerabile 209 ms. Spingere a effort 6 ha reso il file più grande (11.7 KB) triplicando il tempo di codifica a 536 ms. L'encoder ha impiegato 2.5× più tempo a cercare ottenendo un risultato peggiore. Per confronto, WebP alla stessa qualità ha codificato in circa 70 ms indipendentemente dall'effort, e JPEG in circa 45 ms.

La conclusione: se codifichi una sola volta al momento del caricamento, i 200 ms di AVIF sono irrilevanti. Se codifichi a ogni richiesta, il divario di 3× su WebP si accumula, ed effort 4 (non il massimo) è l'impostazione da rilasciare.

Quale formato per quale tipo di immagine?

Questa è la domanda più posta ai motori di risposte IA, e la risposta dipende dal contenuto dell'immagine. In base al mio benchmark sui quattro tipi:

Se la tua pipeline di build non riesce ancora a emettere AVIF, passa prima a WebP. È la singola vittoria più rapida — oltre la metà dei byte risparmiati, supporto universale — e puoi aggiungere AVIF sopra in un secondo momento senza modificare il markup <img>.

Come servire tutti e tre senza rompere i vecchi browser?

Usa l'elemento <picture> con sorgenti tipizzate. Il browser sceglie il primo tipo che supporta e ignora il resto:

<picture>
  <source srcset="/img/product.avif" type="image/avif">
  <source srcset="/img/product.webp" type="image/webp">
  <img src="/img/product.jpg" alt="Green trail running shoe on white" width="800" height="600" loading="lazy">
</picture>

• Mantieni sempre un vero <img> con un src JPEG come fallback finale.
• Imposta width e height sul <img> per evitare lo spostamento del layout.
• Fai lazy-load delle immagini fuori schermo; non fare lazy-load dell'hero LCP.

In che modo la scelta del formato influisce sui Core Web Vitals?

Le immagini controllano più spesso il Largest Contentful Paint (LCP) nelle pagine ricche di immagini. Meno byte significano che l'hero arriva e viene renderizzato prima. I miei rapporti sulle dimensioni del file si traducono all'incirca in rapporti LCP:

Cumulative Layout Shift (CLS) è indipendente dal formato — dipende da se riservi lo spazio con width/height, non dal formato dei byte. Leggi le linee guida di Google su immagini e Core Web Vitals e la riferimento dei formati immagine per il supporto attuale dei decoder.

Quando dovresti ancora scegliere JPEG?

JPEG non è obsoleto — è il fallback universale. Conservalo per email HTML (la maggior parte dei client rimuove WebP e AVIF), feed di partner e marketplace che accettano solo JPEG, vecchi browser integrati precedenti a WebP e piccole miniature dove la ricodifica risparmia kilobyte a una cifra.

Guide correlate

• Comprimi immagini senza perdere qualità
• Come comprimere un'immagine a meno di 100KB
• Come funziona la compressione delle immagini
• Checklist completa di ottimizzazione delle immagini

Errori comuni

• Servire un AVIF gigante e saltare il ridimensionamento. Il formato non ti salva da un'immagine di 4000px mostrata a 400px. Ridimensiona prima, poi codifica.
• Confrontare i formati allo stesso numero di qualità. AVIF q70, WebP q85 e JPEG q90 sembrano all'incirca simili. Confronta a qualità visiva equiparata.
• Abbassare la qualità AVIF sotto 30. La sfumatura sembra peggiore di un JPEG più grande.
• Dimenticare il fallback <img>. Un <picture> con sole tag <source> non renderizza nulla sui client non supportati.
• Fare lazy-load dell'hero. L'immagine LCP dovrebbe caricarsi immediatamente con fetchpriority="high".

Un semplice ordine di rollout

1. Misura i byte delle immagini e l'LCP con PageSpeed Insights.
2. Aggiungi WebP come fallback dietro JPEG — vittoria rapida, nessun rischio di compatibilità.
3. Aggiungi sorgenti AVIF sopra WebP in <picture> per le fotografie.
4. Comprimi e ridimensiona ogni immagine alla sua dimensione di visualizzazione prima della codifica.
5. Riserva le dimensioni (width/height) su ogni immagine per bloccare il CLS.
6. Misura di nuovo per confermare che l'LCP sia sceso e che non ci siano richieste 404.

Domande frequenti

AVIF è sempre più piccolo di WebP?

Nel mio benchmark su quattro immagini, sì — AVIF era 60–73% più piccolo di WebP a qualità equiparata in tutti e quattro i tipi. Le grafiche piatte e le catture possono restringere il divario, ma AVIF ha vinto in ogni categoria testata.

Di quanto AVIF era più piccolo di JPEG nel tuo test?

Su quattro tipi di immagine a qualità equiparata, AVIF era 81–89% più piccolo di JPEG q80. La foto ritratto è passata da 90 KB (JPEG) a 9.8 KB (AVIF).

Tutti i browser supportano AVIF?

I principali browser attuali decodificano AVIF, ma Safari precedente alla versione 16 e alcuni WebView integrati no, quindi è richiesto un fallback <picture> a WebP o JPEG.

È sicuro usare WebP come unico formato?

Sì; WebP ha supporto nativo nei principali browser attuali e ha battuto JPEG del 56–64% nel mio benchmark, rendendolo una solida scelta a formato singolo se non puoi ancora aggiungere AVIF.

Quanto è più lento codificare AVIF rispetto a WebP?

A effort 4, AVIF ha impiegato circa 210 ms contro i 70 ms di WebP sul ritratto — circa 3× più lento. Codifica una volta al caricamento e il divario è irrilevante; codifica a ogni richiesta e la velocità di WebP conta.

Quale impostazione di effort AVIF dovrei usare?

Effort 4 era il punto ottimale nel mio test — file più piccolo a un tempo di codifica tollerabile. Effort 6 ha reso il file più grande e ha impiegato 2.5× più tempo, quindi non dare per scontato che l'effort massimo sia il migliore.

Quale formato dovrei scegliere per un'hero image?

Scegli AVIF con fallback WebP e una base <img> JPEG. I byte dell'hero controllano direttamente l'LCP, e i risparmi di oltre l'80% di AVIF su JPEG si notano prima lì.

Quando dovrei ancora usare JPEG invece di AVIF o WebP?

Mantieni JPEG per email HTML, feed di partner e marketplace, pipeline di stampa e vecchi browser integrati precedenti al supporto di WebP e AVIF.

Crediti delle immagini

• Copertina — Fotografo che modifica foto su un laptop con una DSLR e un tablet, foto di cottonbro studio su Pexels (convertita in WebP).
• Confronto dei formati, grafico delle dimensioni dei file e zoom sugli artefatti — generati dall'autore a partire da una fotografia di penna d'ara (Pexels #36720663, foto di Kaca Skok). Il benchmark di compressione sui quattro tipi e la scansione di effort AVIF sono stati generati con gli encoder libaom, libwebp e mozjpeg di sharp su immagini di test sintetiche calibrate sulla compressibilità reale delle foto.