AVIF vs WebP vs JPEG: numeri reali a parità di qualità

La maggior parte delle affermazioni del tipo “AVIF è il 50% più piccolo di JPEG” mette a confronto un JPEG a qualità 75 con un AVIF con un’impostazione diversa. Non è un confronto: un -q 75 in un encoder non è la stessa immagine di un -q 75 in un altro. L’unica domanda onesta è: a qualità percepita fissa, quanti byte servono a ciascun formato?

Lo abbiamo misurato. Non su una manciata di immagini di punta, ma su oltre 1.900 fotografie reali, con gli encoder reali, valutate con una metrica percettiva invece che con un numero di qualità indovinato.

Come lo abbiamo misurato

• Immagini: il set di foto del nostro benchmark pubblico — 1.998 fotografie reali, per lo più originali di Wikimedia Commons, che spaziano tra ritratti, paesaggi, texture, scarsa luminosità e dettagli fini. Non un caso scelto ad arte.
• Encoder, ciascuno lo strumento standard: JPEG tramite libjpeg-turbo, WebP tramite cwebp (libwebp), AVIF tramite avifenc (libaom), e JPEG XL tramite cjxl (libjxl) come bonus.
• La metrica: ssimulacra2, un punteggio di qualità percettiva dove un valore più alto significa più vicino all’originale. Si correla con ciò che vede l’occhio molto meglio del PSNR o di un semplice numero di qualità. 90+ è indistinguibile dalla fonte; ~85 è alta qualità; ~80 è buono.
• Il metodo: per ogni immagine, codifichiamo ciascun formato lungo un’intera griglia di qualità, valutiamo ogni output con ssimulacra2 e poi interpoliamo il numero di byte che quel formato richiede per raggiungere un punteggio target. Questo è il confronto onesto: ogni formato è vincolato alla stessa qualità percepita, e da lì leggiamo il prezzo in byte. Riportiamo la mediana sulle immagini in cui tutti i formati raggiungono davvero il target.

Quell’ultimo punto conta: confrontare cwebp -q 80 con avifenc -q 80 non ha senso. Confrontare “il WebP che sembra bello quanto l’AVIF” è tutto il gioco.

I numeri

A ssimulacra2 85 (alta qualità, difficile da distinguere dall’originale) — le 548 foto in cui tutti e quattro i formati lo raggiungono:

A parità di qualità, AVIF è il 16% più piccolo di WebP, ed entrambi battono JPEG con largo margine.

A ssimulacra2 80 (buona qualità, un target web comune) — su 1.884 foto:

Il vantaggio di AVIF si allarga a 80 (−29% vs JPEG, −21% vs WebP): mantiene il dettaglio a bitrate più bassi, dove JPEG e WebP iniziano a sfaldarsi.

Questi dati sono coerenti con la letteratura indipendente: un AVIF che si colloca circa il 25-30% sotto JPEG a parità di qualità è un risultato ampiamente replicato. Quello che aggiunge questa misurazione è che è calcolata in modo percettivo, a parità di qualità, su un set di foto ampio e non selezionato ad arte.

Le avvertenze, dette senza giri di parole

• La base JPEG è libjpeg-turbo, il JPEG che quasi tutto usa oggi. Gli encoder JPEG moderni (mozjpeg, jpegli) colmano parte del divario restando pienamente compatibili con JPEG: se puoi servire solo JPEG, passa a uno di questi prima di ogni altra cosa.
• WebP ha di fatto un tetto di qualità. Il suo encoder lossy ha un limite: sulle foto ad alto dettaglio fatica persino a raggiungere ssimulacra2 90. È un limite reale, non una scelta di configurazione.
• JPEG XL è il più piccolo qui, ma non puoi distribuirlo ai browser. Nessun browser importante lo abilita di default nel 2026. È incluso come tetto tecnico, non come raccomandazione di deployment.
• AVIF costa tempo di codifica. avifenc è molto più lento di cwebp o cjpeg. Va bene per asset archiviati/su CDN, meno per una codifica al volo su singola richiesta: proprio per questo un servizio orientato alla qualità usa una cache.

Cosa significa questo in pratica

Servi AVIF con fallback a WebP e JPEG, e punta a un punteggio percettivo, non a un numero di qualità. Un -q fisso distribuisce una qualità incoerente tra le immagini: alcune sovracompresse e visibilmente rovinate, altre inutilmente pesanti. Cercare la qualità dell’encoder immagine per immagine per raggiungere un punteggio ssimulacra2 target è ciò che dà sia i byte più piccoli sia una qualità che puoi davvero promettere.

È esattamente ciò che fa Patu: cerca la qualità dell’encoder per ogni immagine per raggiungere un target percettivo, e restituisce AVIF e WebP con fallback JPEG, dietro una CDN. I numeri sopra sono il motivo per cui il default è AVIF-first.

curl -X POST "https://patu.dev/v1/compress?formats=avif,webp,fallback&target=85" \
  -H "X-Api-Key: $PATU_KEY" \
  --data-binary @photo.jpg -o photo.avif

Dai una qualità target; ottieni il file più piccolo a quella qualità, nei formati che un browser può davvero usare.

Metodo e dati: l’harness di benchmark di Patu sulla categoria foto; ssimulacra2 tramite l’implementazione rust-av; encoder libjpeg-turbo, libwebp, libaom, libjxl nelle loro versioni rilasciate. Le dimensioni sono la mediana tra le foto in cui ogni formato raggiunge il punteggio target.