Perché JPEG XL non ha ancora posto nei browser web

Il dibattito sui formati immagine del Web si infiamma

Nel settembre 2026, l'ingegnere di compressione immagini Gianni Rosato ha pubblicato una dettagliata critica tecnica di JPEG XL come codec Web, riaccendendo un dibattito che molti credevano concluso quando Chrome ha rifiutato il formato nel 2023. Rosato, che ha contribuito alla codifica AV1 e AVIF, sostiene che, sebbene JPEG XL sia tecnicamente impressionante e abbia un posto al di fuori del Web, non soddisfa le esigenze specifiche dei browser, in particolare se confrontato con le moderne implementazioni AVIF e WebP.

Il tempismo è notevole: un decoder JPEG XL basato su Rust è recentemente entrato in Firefox e Chrome, sollevando domande sul fatto che i principali attori del Web stiano invertendo la rotta. L'articolo di Rosato, intitolato "The case against JPEG XL", offre un contrappunto empirico basato su benchmark di encoder e architettura del formato, non solo su argomenti politici o ideologici.

Il vantaggio lossless è sopravvalutato

Una delle caratteristiche più celebrate di JPEG XL è la sua compressione lossless. Tuttavia, Rosato sottolinea che il vantaggio lossless del formato rispetto a WebP è solo di circa l'11,9% più piccolo, e questo dato proviene da un dataset di test di immagini estremamente grandi (foto da 157 MP, illustrazioni da 10 MP e libri da 27 MP) che sono ben lontani dai contenuti Web tipici.

"Il consumatore Web medio non ha bisogno di lossless; ha solo bisogno di un codec lossy abbastanza versatile da prevenire artefatti terribili," scrive Rosato. Dato il piccolo volume di contenuti veramente critici per la lossless sul Web, sostiene che il costo dell'aggiunta di un nuovo codec ai browser non sia giustificato da un guadagno così marginale.

Compressione lossy: AVIF ha preso il comando

Quando JPEG XL fu proposto per la prima volta, il suo encoder di riferimento era considerato più ottimizzato percettivamente rispetto ai concorrenti. Ma Rosato sostiene che non è più così. L'encoder di riferimento AV1 e SVT-AV1 hanno entrambi ricevuto una messa a punto percettiva specializzata basata su prove soggettive umane, colmando qualsiasi divario che una volta esisteva.

I benchmark di Rosato, utilizzando metriche come CVVDP, MS-SSIM e SSIMULACRA2, mostrano AVIF superare JPEG XL in tutta la gamma di fedeltà. Evidenzia anche svantaggi strutturali nel design di JPEG XL:

• Nessuna predizione direzionale: A differenza di WebP e AV1, JXL manca di modalità di predizione direzionale, che aiutano a preservare i bordi e risparmiare bit nella codifica a blocchi.
• Debole deblocking: I filtri in-loop di JXL (gaborish e EPF) non sono equivalenti a un filtro deblocking adeguato, portando a rumore di zanzara.
• Codifica patch macchinosa: Per immagini non fotografiche, il meccanismo patch di JXL è molto più complesso e meno efficiente dell'Intra Block Copy di AV1, richiedendo fotogrammi, livelli e logica di blending extra.

Rosato nota anche che lo spazio colore percettivo XYB di JXL, sebbene innovativo, si basa su una quantizzazione aggressiva del canale B, risultando in una conservazione del colore scadente che gli sviluppatori di encoder devono aggirare esplicitamente.

Tempo di decodifica: una debolezza critica

La velocità di decodifica è dove JPEG XL cade più drammaticamente indietro. I confronti a parità di dimensioni di Rosato mostrano la decodifica WebP oltre 10 volte più veloce di jxl-rs, anche quando il file WebP è più grande di 90KB. AVIF, nonostante la sua reputazione di lentezza, supera anche JXL nel tempo di decodifica.

Più preoccupanti sono i casi patologici. Rosato dimostra un'immagine JXL di 1.918 byte che impiega 17,43 secondi per decodificare su un M5 Pro utilizzando il decoder Rust. Con l'arrivo di questo decoder in Chrome e Firefox, tali immagini potrebbero diventare banali strumenti di denial-of-service per dispositivi di fascia bassa. "Puoi già inserirne un paio di dozzine in una pagina Web e rallentare i dispositivi Apple," avverte, notando il supporto nativo di Safari per JXL.

Rendering progressivo e ricompressione JPEG

Il rendering progressivo di JPEG XL, un tempo un punto di forza, è ora eguagliato o superato da AVIF. Rosato indica una demo sul sito informativo di JPEG XL stesso che mostra AVIF fornire un'immagine utilizzabile a solo il 2-3% della dimensione del file, mentre JXL è in ritardo. Nota anche che la decodifica progressiva di JXL non è nemmeno supportata nativamente in Safari, richiedendo un polyfill.

La ricompressione JPEG, convertendo i JPEG esistenti in JXL senza perdita, fa risparmiare circa il 20% di dimensioni ma costa circa il 33% in più di tempo di decodifica. "L'argomento che i risparmi arrivano 'gratuitamente' è fuorviante," dice Rosato, specialmente sul Web dove la velocità di decodifica influisce direttamente sull'esperienza utente.

La politica della scelta del codec

Rosato riconosce la dimensione politica: JPEG XL proveniva da Cloudinary e Google, e il suo rifiuto da parte di Chrome nel 2023 è stato visto da molti come un colpo contro i formati aperti. Ma sostiene che gran parte del supporto per JXL derivi dal desiderio di avere più scelta per gli sviluppatori piuttosto che dalla superiorità tecnica.

"È mia opinione che la maggior parte dell'argomentazione a favore di JPEG XL provenga dal volere un Web con più scelta per gli sviluppatori piuttosto che dal volere un codec immagine tecnologicamente superiore," scrive, sottolineando al contempo che JXL ha ancora un futuro luminoso al di fuori del Web, nella fotografia professionale, nell'hardware delle fotocamere e come formato di interscambio universale.

Il verdetto: un grande formato, ma non per il Web

La conclusione di Rosato è chiara: il design ampio e non mirato di JPEG XL è un peso per il Web, che necessita di codec progettati appositamente, efficienti e con uno scopo ristretto. AVIF, nonostante le sue stranezze di contenitore, beneficia dell'ecosistema maturo AV1 e ora domina l'intera gamma di fedeltà.

"JPEG XL non è inutile; è una tecnologia genuinamente convincente per casi d'uso al di là del Web. Semplicemente non sono personalmente convinto che ne abbiamo bisogno nei browser a breve," conclude. Mentre l'integrazione del decoder Rust procede, questo caso tecnico probabilmente influenzerà il dibattito in corso su quali formati meritino un posto permanente nella piattaforma Web.