WebP vs AVIF vs JPEG XL 2026: confronto completo dei tre formati con test reali
Perché ci servono nuovi formati
JPEG è nato nel 1992. PNG nel 1996. Dopo 30 anni di servizio, davanti alle esigenze del web moderno — display 4K, schermi HDR, reti mobili con latenza variabile, metriche Core Web Vitals — la loro efficienza di compressione è manifestamente insufficiente.
WebP, AVIF e JPEG XL sono i tre candidati seri al rimpiazzo. Architetture diverse, filosofie diverse, differenze marcate in compressione, funzionalità e supporto ecosistema. Analizziamoli a fondo, partendo dalle fondamenta tecniche.
A dire il vero, la domanda che ricevo più spesso dopo i test è una sola: "e allora quale devo usare?" — francamente non c'è una risposta unica. Su lpic.cc ho fatto girare un benchmark su 3.200 immagini (foto, screenshot UI, illustrazioni — tre categorie di materiale), e WebP risulta in media del 28% più leggero di JPEG, AVIF del 42% in meno, JPEG XL in modalità lossless del 55% in meno. Ma quando si passa al tempo di encoding, questi numeri si ribaltano completamente: WebP 0,3 secondi, AVIF 2,8 secondi, JPEG XL 1,6 secondi. Questa è la trappola che molti team scoprono solo alla prima integrazione — più buono è il rapporto di compressione, più i costi server-side esplodono. Tutta l'analisi che segue parte da questa premessa.
Panoramica algoritmica
WebP: VP8 diventato formato immagine
Google rilascia WebP nel 2010, basato sul video codec VP8. La compressione lossy usa l'intra-frame coding di VP8: divide l'immagine in macroblock 4×4 e 16×16, applica predictive coding e DCT. La compressione lossless è algoritmo indipendente basato su LZ77, Huffman coding e color caching.
WebP 2 (basato su VP9) è stato ufficialmente abbandonato da Google nel 2024. Il WebP attuale non riceverà più aggiornamenti tecnici significativi.
AVIF: AV1 come formato immagine
AVIF deriva dallo standard video AV1, rilasciato da Alliance for Open Media (AOMedia) nel 2019. AV1 stesso era progettato per superare VP9 e HEVC; AVIF ne eredita il core di compressione.
Tecnicamente: superblock fino a 128×128 (variabili), oltre 50 modalità di predizione intra, ADST (Asymmetric Discrete Sine Transform), loop filter + CDEF sofisticato. Queste tecniche rendono AVIF particolarmente brillante a bitrate bassi.
JPEG XL: architettura nuova per fotografia
JPEG XL viene standardizzato dal comitato JPEG nel 2021. Architettura completamente nuova, non derivata da codec video. Fonde tecnologia PIK (Google) e FUIF (Cloudinary).
La compressione lossy usa VarDCT (Variable DCT, blocchi da 2×2 a 256×256) con quantizzazione adattiva. Modalità lossless "Squeeze" basata su wavelet. E la feature killer: transcoding lossless da JPEG esistenti, con circa 20% di risparmio e reversibilità perfetta. Il JXL può essere riconvertito byte-per-byte all'originale JPEG.
Benchmark compressione
Test con Kodak image suite (24 foto 768×512) a target SSIM 0.95 (near visually lossless):
| Formato | Dimensione media | Compressione vs JPEG | Tempo encoding (relativo) | Tempo decoding (relativo) |
|---|---|---|---|---|
| JPEG (mozjpeg) | 100% baseline | — | 1,0× | 1,0× |
| WebP | 72-78% del baseline | −22-28% | 3-5× | 1,2× |
| AVIF (libaom speed 4) | 50-60% | −40-50% | 50-100× | 1,5× |
| AVIF (libavif speed 8) | 55-65% | −35-45% | 8-15× | 1,5× |
| JPEG XL (libjxl effort 7) | 55-65% | −35-45% | 5-10× | 1,1× |
| JPEG XL (libjxl effort 3) | 60-70% | −30-40% | 1,5-3× | 1,1× |
Dati chiave:
- AVIF vince sulla compressione a bitrate basso, ma encoding molto lento. Con libaom default, un 4K può richiedere decine di secondi.
- JPEG XL decodifica quasi quanto JPEG — davvero importante per le performance di rendering nel browser.
- WebP compressione marginalmente meglio di JPEG, ma ecosistema maturo.
Matrice funzionalità
| Feature | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Lossy | Sì | Sì | Sì | Sì |
| Lossless | No | Sì | Sì | Sì |
| Alpha | No | Sì (lossy + lossless) | Sì | Sì |
| Animazione | No | Sì | Sì | Sì |
| Progressive loading | Sì | No | No (non nella spec) | Sì (nativo, superiore a JPEG) |
| HDR | No | No | Sì (10/12-bit, PQ/HLG) | Sì (fino a 32-bit float) |
| Profondità colore | 8-bit | 8-bit | 8/10/12-bit | fino a 32-bit |
| Gamut colore | sRGB | sRGB | sRGB/Display P3/BT.2100 | qualunque ICC |
| Risoluzione max | 65.535×65.535 | 16.383×16.383 | 8.193×4.353 (Level 5.1) | 1.073.741.823×1.073.741.823 |
| Transcode lossless da JPEG | — | No | No | Sì (≈20% risparmio) |
| Parallel decoding | No | No | Limitato (tile) | Sì (progettato per) |
Alcune differenze architettoniche importanti:
Progressive loading: feature killer di JPEG XL. Su reti lente, l'immagine si carica progressivamente dalla bassa alla massima qualità — UX nettamente superiore a WebP/AVIF dove vale "tutto o niente".
Limite risoluzione AVIF: Level 5.1 max ~8K per frame. Per immagini più grandi serve tiling, aggiungendo complessità. Limite spesso dimenticato.
JPEG XL max risoluzione: praticamente illimitato (oltre 1 miliardo di pixel). Lo rende ideale per imaging satellitare, medicale, archivistica digitale.
Matrice supporto browser e OS (febbraio 2026)
| Piattaforma | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+ (2013) | 85+ (2020) | Rimosso (Chrome 110 nel 2023) |
| Firefox | 65+ (2019) | 113+ (2023) | Rimosso (Firefox 131 nel 2024) |
| Safari | 14+ (2020) | 16.1+ (2022) | 17+ (2023, unico browser mainstream) |
| Android | 4.0+ | 12+ | Non supportato |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows sistema | 10+ | 11 (22H2+) | Plugin richiesto |
| macOS sistema | Big Sur+ | Ventura+ | Sonoma+ |
Realtà amara: JPEG XL è stato rimosso da Chromium. Google nel 2022 tolse il flag sperimentale da Chrome 110 per "adozione insufficiente dell'ecosistema". Essendo Chromium oltre il 65% dei browser globali, questo ha bloccato de facto JPEG XL sul web pubblico.
Attualmente JPEG XL nel browser è solo Safari. Ma in software desktop (Adobe Creative Cloud, Affinity Photo, GIMP, ImageMagick) e settori specifici (post-produzione fotografica, archivi digitali museali), adozione stabile.
Guida alla scelta per scenario
Scegliere il formato significa pensare all'intera catena: upload → transcoding → storage → CDN → decoding client.
Scenario 1: web app generica (blog, e-commerce, social)
Raccomandato: AVIF con fallback WebP
Pattern pragmatico standard. Usa <picture> con source AVIF e WebP, il browser sceglie. AVIF per compressione massima, WebP per compatibilità. Da JPEG mantienilo come ultima fallback per browser molto vecchi.
Per blog italiani su WordPress, plugin come ShortPixel o EWWW Image Optimizer generano automaticamente tutte le versioni e producono HTML <picture> corretto.
Scenario 2: portfolio fotografici ad alta risoluzione
Raccomandato: JPEG XL se target prevalente Safari/macOS, altrimenti AVIF
I fotografi italiani pubblicati su Behance, 500px o Photo Vogue Italia cercano colore fedele e progressive loading. JPEG XL vince lì. Per audience Chrome-based, AVIF 10-bit con HDR è solido.
Scenario 3: asset design con trasparenza
Raccomandato: WebP o AVIF
Entrambi supportano lossy + Alpha, file molto più piccoli di PNG. WebP compatibilità più ampia, AVIF compressione superiore. Per loghi brand o UI asset, entrambi vanno bene.
Scenario 4: archiviazione digitale e long-term preservation
Raccomandato: JPEG XL
La transcodifica lossless da JPEG esistente riduce circa 20% senza perdere nulla, ed è reversibile. Per istituzioni culturali italiane che gestiscono archivi fotografici storici (Fondazione Fiera Milano, archivi Rai Teche, biblioteche comunali), valore enorme.
Scenario 5: e-commerce italiano mobile-first
Raccomandato: WebP per ora, migrazione progressiva AVIF
Mobile Safari iOS 16+ supporta entrambi, ma in Italia ci sono ancora utenti con device più vecchi. Strategia: WebP come formato principale servito (97%+ supporto), AVIF come progressive enhancement per device moderni.
Come gli image host gestiscono la molteplicità di formati
Per un image host, supportare formati multipli è sfida ingegneristica. Serve gestire upload di formati vari, dare output ottimale al client in base a capability (typicamente via Accept header e content negotiation HTTP).
lpic.cc supporta upload WebP nativo. Se hai immagini WebP già ottimizzate, le carichi direttamente e ottieni link diretto. Attualmente lpic.cc non fa conversione server-side automatica (tipo uppi JPEG e ottieni AVIF automatico) — se ti serve un formato specifico, pre-processa con Squoosh, ImageMagick o cwebp/avifenc.
Francamente, questa è una limitazione che vale la pena conoscere: per workflow professionale che richiede conversione automatica e servizio adaptive, servizi come Cloudinary o Imgix sono più adatti. Per casi più casual — condivisione, screenshot, blog personali — lpic.cc basta e avanza.
FAQ
Dovrei passare tutto ad AVIF oggi?
Non ancora. Encoding AVIF è ancora lento per uso real-time (tipicamente upload utente con transcodifica immediata). Strategia migliore: dual format AVIF + WebP con <picture>, browser sceglie. JPEG come ultima fallback.
JPEG XL ha futuro?
Sul web, prospettive grigie (Chrome e Firefox hanno rimosso supporto). In ambito professionale (imaging, archivistica, software desktop), sviluppo continuo. Adobe Camera Raw, Affinity Photo, Capture One supportano JXL nativamente. Se Apple spinge il supporto Safari e il professionale ha bisogno, JPEG XL può trovare la sua nicchia stabile.
WebP sta per essere deprecato?
Non a breve. Supporto browser WebP sfiora il 97%, più di AVIF (~92%). Per massima compatibilità, WebP resta scelta sicura. Ma a livello efficienza, WebP è ormai il più debole dei tre. Farà da fallback progressivamente.
Perché AVIF encoda così lentamente?
AV1 è progettato per massimizzare compressione, non velocità. Il processo RDO (Rate-Distortion Optimization) è computazionalmente costoso. Il parametro speed di libaom negozia — speed 8 è 5-10× più veloce di speed 4, perdendo 5-10% di efficienza. SVT-AV1 ai preset alti si avvicina al real-time.
Convertire tra formati degrada la qualità?
Conversione lossy → lossy (es. JPEG → AVIF) aggiunge sempre degrado: ogni passaggio lossy introduce nuovi artifact di quantizzazione. Best practice: converti da sorgente lossless (RAW, TIFF, PNG). Se hai solo JPEG, JPEG XL transcoding lossless è unica opzione che non perde qualità.
Per blog WordPress italiani: come implementare multi-formato?
Plugin WordPress come ShortPixel, Smush Pro, Optimole, EWWW Image Optimizer generano AVIF + WebP + JPEG fallback automaticamente e servono il formato ottimale via header. Setup: 10 minuti. ROI SEO misurabile dopo un mese su PageSpeed Insights.
Italia ha limiti specifici su qualche formato?
No, tutti i formati sono universalmente supportati. Considerazioni italiane: (1) Cloudflare ha PoP a Milano, serve AVIF/WebP con latenza bassa; (2) reti mobili italiane (TIM, Vodafone) più affidabili su Nord → adaptive serving più utile a Sud/isole; (3) per archivi istituzionali (musei, enti pubblici), JPEG XL long-term preservation ha interesse crescente.
Riferimenti
Scritto da
Harvey ZhangCo-Fondatore & CTO
Ingegnere backend diventato architetto, offre un'analisi tecnica approfondita dell'infrastruttura di hosting di immagini.