JPEG XL e Core Web Vitals: cosa devi sapere ora che Chrome lo integra

JPEG XL sta finalmente tornando su Chrome

Dopo tre anni di controversie, JPEG XL è tornato su Chromium. Chrome 145, rilasciato all'inizio di febbraio 2026, include un decoder JPEG XL. Ancora dietro un flag, ma funzionalmente presente nel codice per la prima volta dalla sua controversa rimozione alla fine del 2022. Questo è importante perché JPEG XL è dimostrabilmente superiore a ogni formato immagine web esistente nella maggior parte delle dimensioni tecniche: dal 50 al 60% più piccolo di JPEG, dal 10 al 15% di compressione migliore rispetto ad AVIF a velocità di codifica equivalenti, e l'unico formato moderno con vera decodifica progressiva. Per i professionisti delle prestazioni web, la traiettoria del formato — da standard ISO a esilio da Chrome fino alla resurrezione — rappresenta sia un'opportunità tecnica che un monito sul potere dei vendor di browser sulla piattaforma web.

Il supporto browser a febbraio 2026 è solo del 12%

Il supporto browser globale effettivo di JPEG XL si attesta intorno al 12%, quasi interamente dagli utenti Safari. Quel numero sta per cambiare. Ma la tempistica rimane incerta.

Safari 17+ (rilasciato a settembre 2023) fornisce la decodifica nativa JPEG XL su macOS Sonoma, iOS 17, iPadOS 17, watchOS e visionOS. L'implementazione di Apple delega la decodifica al framework immagini a livello di sistema operativo, il che significa che funziona ovunque Safari sia disponibile. Tuttavia, il supporto di Safari è esplicitamente parziale: nessun supporto per le animazioni e nessuna decodifica progressiva. Due delle caratteristiche più distintive di JPEG XL. Questa è una limitazione significativa che ridimensiona la proposta di valore completa del formato sui dispositivi Apple.

Chrome 145 (febbraio 2026) reintroduce JPEG XL tramite un decoder in puro Rust chiamato jxl-rs, che sostituisce la precedente implementazione in C++ libjxl. Il decoder è protetto dal flag chrome://flags/#enable-jxl-image-format e non è abilitato di default. Google ha stabilito condizioni chiare per l'attivazione predefinita: un impegno alla manutenzione a lungo termine e il soddisfacimento dei criteri di lancio standard. Il decoder Rust attualmente opera entro il 15-25% della velocità dell'implementazione di riferimento in C++, con 26 PR di ottimizzazione integrate solo a dicembre 2025. Le funzionalità confermate includono profili colore ICC, animazioni, alfa/trasparenza, ampia gamma cromatica (Display P3) e HDR (PQ/HLG).

Firefox rimane il più indietro. Il formato è disponibile solo in Firefox Nightly dietro il flag image.jxl.enabled. Aspetto critico: il codice del decoder non è compilato nelle build stabili, quindi il flag non ha effetto su Firefox release. La posizione di Mozilla è passata da "negativa" a "neutrale", con lavoro attivo (Bug 1986393) per integrare lo stesso decoder Rust jxl-rs. Non esiste una tempistica per il supporto stabile.

Edge, in quanto derivato di Chromium, probabilmente contiene il codice jxl-rs da Chrome 145 ma non ha annunciato o documentato ufficialmente il supporto JPEG XL. Le note di rilascio di Edge 145 non ne fanno menzione.

Interop 2026 ha incluso JPEG XL come area di indagine (non come area di focus completa), con la partecipazione di Apple, Google, Microsoft e Mozilla. Questo segnala un'intenzione condivisa tra i vendor di costruire suite di test complete, il che tipicamente precede una distribuzione più ampia.

Come JPEG XL supera ogni alternativa. E dove non lo fa

La storia dell'efficienza di compressione è sfumata e dipende fortemente dal tipo di contenuto e dal bitrate. Al livello più alto, JPEG XL vince i confronti più importanti nel mondo reale.

Contro JPEG

I miglioramenti sono notevoli. JPEG XL raggiunge una qualità visivamente lossless a circa 1,2 bit per pixel dove JPEG ne richiede 2,4 bpp. Un miglioramento di 2:1. Il benchmark di DebugBear su una fotografia da 990 KB ha mostrato JPEG XL a 472 KB (52% di risparmio), rispetto a WebP a 700 KB e AVIF a 507 KB. I test di Cloudinary su oltre 40.000 immagini hanno rilevato che JPEG XL a effort 6 produceva file 20% più piccoli di AVIF con una codifica 2,5 volte più veloce.

Contro AVIF

Il confronto dipende dal bitrate. A bassi bitrate sotto 0,4 bpp (compressione pesante), AVIF supera JPEG XL. Produce immagini più uniformi con meno artefatti. A bitrate medi e alti (0,4 bpp e oltre), dove si colloca la maggior parte della fotografia web, JPEG XL vince costantemente nella preservazione dei dettagli e nella fedeltà. Lo stesso studio comparativo di Google su AVIF ha mostrato che 9 metriche di qualità su 13 favorivano JPEG XL a impostazioni pratiche di velocità del codificatore. Il divario nella velocità di codifica è enorme: AVIF (tramite libaom) è un ordine di grandezza più lento di JPEG XL nella codifica single-threaded. Alle impostazioni più lente di AVIF (~0,5 Mpx/s), esso eguaglia la densità di compressione della seconda impostazione più veloce di JPEG XL a 52 Mpx/s. Una differenza di velocità di 100 volte.

Contro WebP

JPEG XL vince in modo netto. WebP è limitato a una profondità di colore di 8 bit, sottocampionamento cromatico 4:2:0 in modalità lossy e una risoluzione massima di 16.383 x 16.383 pixel. JPEG XL supporta fino a 32 bit per canale (intero o virgola mobile), risoluzioni superiori a 1 miliardo di pixel per lato e non ha vincoli di sottocampionamento cromatico.

Il tipo di contenuto conta

Per tipi di contenuto specifici, i benchmark di DebugBear hanno rivelato un quadro più variegato. AVIF ha vinto sui loghi (2 KB contro i 6 KB di JXL) e sulle immagini con trasparenza (18 KB contro 63 KB), mentre JPEG XL ha vinto sulle fotografie (472 KB contro 507 KB) e sui contenuti animati dove ha raggiunto una compressione del 99% (14 KB da un GIF di 1,3 MB, contro i 56 KB di AVIF). Questi risultati utilizzavano le impostazioni predefinite di Cloudinary, quindi rappresentano output tipici piuttosto che ottimizzati.

Confronto delle caratteristiche

Due caratteristiche che nessun altro formato può eguagliare

Le caratteristiche strategicamente più importanti di JPEG XL sono la decodifica progressiva e la transcodifica lossless JPEG. Nessun concorrente offre nessuna delle due.

Decodifica progressiva

La decodifica progressiva cambia radicalmente il modo in cui le immagini vengono caricate. I file JPEG XL sono sempre progressivi almeno a 8x8; il frame DC (bassa frequenza) viene sempre codificato per primo. Con solo ~1% dei dati del file scaricati, appare un'anteprima dell'immagine completa utilizzabile. Confrontalo con il JPEG progressivo, che richiede dal 10 al 15% per la sua prima scansione. Cosa ancora più importante, JPEG XL supporta la progressione ordinata per salienza: modelli di machine learning possono identificare le regioni visivamente più importanti (volti nei ritratti, dettagli dei prodotti nell'e-commerce) e codificare quelle regioni in modo che arrivino per prime. Il decoder uniforma i confini tra le regioni completate e quelle ancora in caricamento.

Questo crea una timeline di rendering diversa. AVIF richiede l'immagine compressa completa prima che la decodifica possa iniziare: il tempo totale equivale al tempo di download più il tempo di decodifica, in sequenza. JPEG XL sovrappone trasferimento e decodifica, così l'utente vede contenuti significativi molto prima. Cloudinary ha evidenziato che il rendering progressivo di JPEG XL elimina la necessità di file separati Low Quality Image Placeholder (LQIP), rimuovendo completamente i byte ridondanti. Tuttavia, è importante notare che l'implementazione attuale di Safari non supporta la decodifica progressiva, il che limita questo vantaggio alle future implementazioni di Chrome e Firefox.

Transcodifica lossless JPEG

La transcodifica lossless JPEG è la caratteristica nascosta di JPEG XL. Il formato può copiare direttamente i coefficienti dei blocchi DCT di JPEG nei propri blocchi VarDCT, migliorando solo la codifica entropica. Il risultato: ~20% di riduzione media delle dimensioni del file (intervallo: dal 13 al 22%) con il file JPEG originale ricostruibile bit per bit dal file JXL. Nessun altro formato può farlo. La transcodifica in WebP o AVIF richiede la decodifica in pixel e la ricodifica, causando perdita generazionale. L'API DICOM di Google Cloud Platform utilizza già questa funzionalità per ridurre le dimensioni dei file di imaging medico del 20%.

Su scala web, se tutti gli attuali JPEG venissero transcodificati in modo lossless in JXL, il risparmio di banda sarebbe enorme. La comunità JPEG XL stima un risparmio energetico equivalente all'alimentazione di circa 487.000 case statunitensi per un'ora al giorno.

Cosa significa questo per i Core Web Vitals

JPEG XL influisce su ogni metrica Core Web Vitals attraverso meccanismi diversi, e la relazione è più sfumata di "file più piccoli = punteggi migliori".

LCP (Largest Contentful Paint)

LCP beneficia di due effetti combinati. Primo, le dimensioni dei file ridotte diminuiscono la Resource Load Duration. La fase di download. Una riduzione del 52% rispetto a JPEG significa che l'immagine hero arriva circa due volte più velocemente su connessioni con banda limitata. Secondo, JPEG XL decodifica più velocemente di AVIF, riducendo l'Element Render Delay. La complessa decodifica di AVIF, derivata da codec video, può creare un overhead CPU significativo sui dispositivi mobili, dove un AVIF più piccolo che si scarica più velocemente può essere parzialmente vanificato da un tempo di decodifica più lungo. La velocità di decodifica di JPEG XL fino a 132 Mpx/s e l'ottimizzazione SIMD minimizzano questo collo di bottiglia. Tuttavia, LCP viene misurato quando l'immagine è completamente renderizzata, quindi la decodifica progressiva non migliora direttamente il timestamp LCP. Migliora la performance percepita, che conta per la user experience anche se non sposta la metrica.

CLS (Cumulative Layout Shift)

CLS non dipende dal formato. Tutti i formati beneficiano ugualmente degli attributi espliciti width e height. JPEG XL codifica le informazioni sulle dimensioni negli header iniziali, il che potrebbe teoricamente aiutare i browser ad allocare spazio più velocemente, ma l'impatto pratico è trascurabile rispetto al semplice impostare le dimensioni in HTML.

INP (Interaction to Next Paint)

INP può essere influenzato dalla decodifica pesante delle immagini sul thread principale. La decodifica più veloce e l'ottimizzazione SIMD di JPEG XL significano meno blocco del thread principale rispetto ad AVIF, sebbene entrambi i formati siano tipicamente decodificati fuori dal thread principale nei browser moderni.

Impatto nel mondo reale

La pagina web mediana nel 2025 carica 19 immagini su mobile per un peso totale di 911 KB (HTTP Archive Web Almanac 2025). Convertire queste immagini da JPEG a JPEG XL farebbe risparmiare circa 450-550 KB per pagina. Un miglioramento sostanziale per gli utenti su reti limitate. Con il peso mediano delle immagini desktop di 1.058 KB, il risparmio si avvicina ai 500-630 KB.

Servire JPEG XL oggi con fallback appropriati

L'implementazione richiede una strategia a livelli: l'elemento <picture> per le immagini HTML, la content negotiation lato server per CSS e immagini referenziate dinamicamente, e l'automazione CDN dove disponibile.

L'elemento picture

L'elemento <picture> fornisce l'approccio client-side più pulito. I browser valutano gli elementi <source> dall'alto verso il basso e utilizzano il primo formato supportato:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Descrizione" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Per le immagini responsive, ogni source necessita del proprio srcset con descrittori di larghezza. Creando un'esplosione combinatoria di oltre 12 varianti per immagine (3 o 4 formati x 3 o 4 dimensioni). È qui che l'automazione CDN diventa essenziale.

Content negotiation lato server

La content negotiation lato server ispeziona l'header Accept. Safari 17+ invia image/jxl nel suo header Accept. La configurazione Nginx mappa questo alle estensioni dei file:

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

Il dettaglio critico: includi sempre Vary: Accept nell'header di risposta affinché i CDN e le cache proxy memorizzino varianti separate per formato. Senza questo, una risposta JXL in cache verrà servita ai browser che non possono decodificarla.

Supporto CDN

Il supporto CDN è disomogeneo. Cloudinary offre pieno supporto JPEG XL tramite il suo parametro f_auto. Non sorprende dato che Cloudinary ha co-creato il formato e già distribuisce circa 1 miliardo di immagini JPEG XL al giorno. L'Image Optimizer di Fastly ha aggiunto pieno supporto JPEG XL a luglio 2024, utilizzando effort di codifica 3 con 4 thread e dichiarando ~60% di risparmio rispetto a JPEG. Cloudflare, nonostante la forte domanda della comunità, non supporta la conversione JPEG XL nel suo prodotto Image Resizing. Può memorizzare in cache varianti JXL dalla tua origine tramite Vary: Accept, ma non può generarle. AWS CloudFront, Akamai e Azure non hanno supporto nativo JPEG XL.

Strumenti

Gli strumenti per generare file JPEG XL si concentrano su cjxl dall'implementazione di riferimento libjxl. Parametri chiave: -d per la distanza (0 = lossless, 1,0-2,0 per qualità lossy web), -e per l'effort (da 1 a 9, default 7) e -p per la codifica progressiva. Per input JPEG, cjxl input.jpg output.jxl esegue la transcodifica lossless per impostazione predefinita. Il percorso di migrazione più semplice possibile. Anche ImageMagick, libvips (dalla versione 8.11) e Photoshop v25 supportano JXL. Tuttavia, sharp (la libreria immagini Node.js che alimenta Next.js) non espone ancora l'output JXL, il che significa che Next.js non ha supporto nativo JPEG XL. Il supporto nel core di WordPress è tracciato come ticket #52788, contrassegnato "maybelater".

La decisione di Halloween e la sua inversione dopo tre anni

La storia politica di JPEG XL in Chrome è un caso di studio sul potere dei vendor di browser sugli standard web. Comprenderla è importante perché rivela le forze che determinano quali tecnologie raggiungono gli utenti.

Il 31 ottobre 2022. Soprannominata la "decisione di Halloween". Jim Bankoski del team Chrome di Google ha annunciato la rimozione del supporto sperimentale a JPEG XL. Le ragioni dichiarate erano quattro: i flag sperimentali non dovrebbero rimanere indefinitamente; insufficiente interesse dell'ecosistema; insufficienti benefici incrementali rispetto ai formati esistenti; e onere di manutenzione. Bankoski ha suggerito WebAssembly come "un ottimo percorso in avanti" per chi desiderava JPEG XL in Chrome.

La reazione negativa è stata immediata e prolungata. L'issue su Chromium è diventato il secondo più stellato nell'intera storia del progetto, con oltre 1.000 voti positivi e commenti da rappresentanti di Intel, Adobe, Meta, Shopify, The Guardian, Flickr e della Krita Foundation. Jon Sneyers, co-creatore di JPEG XL presso Cloudinary, ha pubblicato una dettagliata confutazione tecnica ("The Case for JPEG XL") mostrando che i test comparativi pubblicati da Google utilizzavano implementazioni JPEG XL con bug e metriche distorte a favore di AVIF. La Free Software Foundation ha definito la decisione di Google la prova che Google Chrome era diventato l'arbitro degli standard web e ha accusato l'azienda di agire nel proprio interesse. Dato che AVIF deriva da AV1, sviluppato dalla Alliance for Open Media co-fondata da Google.

L'ironia non è sfuggita agli osservatori: Google stessa ha co-creato JPEG XL attraverso il suo progetto PIK, rendendo la decisione di eliminarlo da Chrome ancora più confusa. Quando JPEG XL è stato proposto per Interop 2024, ha ricevuto 646 reazioni dalla comunità. 4,5 volte la seconda proposta. Ed è stato respinto con solo "mancanza di consenso" come spiegazione.

Ciò che alla fine ha invertito la decisione è stato lo slancio dell'ecosistema che ha reso l'assenza di Chrome insostenibile. Apple che ha rilasciato Safari 17 con supporto JPEG XL a settembre 2023 è stata la prima svolta importante. Mozilla che è passata da "negativa" a "neutrale" e poi a disposta attivamente a implementare (con un decoder Rust) ha aggiunto pressione. L'annuncio della PDF Association di JPEG XL come formato HDR preferito per PDF nell'ottobre 2025 potrebbe essere stato il punto di svolta. Il visualizzatore PDF integrato di Chrome avrebbe avuto bisogno del supporto JXL per rimanere conforme. Il 21 novembre 2025, Rick Byers (Chrome Architecture Tech Lead) ha pubblicato l'inversione di rotta, accogliendo contributi per integrare un decoder JPEG XL performante e memory-safe in Chromium. A gennaio 2026, il decoder basato su Rust jxl-rs è stato integrato, e Chrome 145 lo ha rilasciato dietro un flag a febbraio 2026.

Conclusione: preparati ora, implementa gradualmente

JPEG XL è tecnicamente il miglior formato immagine general-purpose disponibile. Compressione migliore di AVIF a velocità di codifica pratiche, decodifica progressiva che nessun concorrente offre, e transcodifica lossless JPEG che fornisce un risparmio istantaneo del 20% con zero perdita di qualità. Gli ostacoli politici che hanno bloccato la sua adozione per tre anni si stanno dissolvendo: Chrome ha il codice nel repository, Firefox sta attivamente integrando lo stesso decoder Rust, e Safari supporta il formato dal 2023.

Il percorso pratico per i team di prestazioni web è chiaro. Inizia a generare varianti JXL adesso. La transcodifica lossless JPEG tramite cjxl è banalmente automatizzabile e fornisce un risparmio immediato del 20% per circa il 12% degli utenti su Safari. Usa gli elementi <picture> o la content negotiation con header Vary: Accept per servire JXL insieme a AVIF, WebP e fallback JPEG. Se il tuo CDN è Cloudinary o Fastly, abilita la distribuzione automatica JXL oggi. La domanda aperta non è se JPEG XL raggiungerà un ampio supporto browser, ma quando Chrome attiverà il flag da off a on per impostazione predefinita. E l'unica risposta onesta è che non è stata annunciata alcuna tempistica. I tre anni di esilio del formato da Chrome dovrebbero temperare l'entusiasmo con pragmatismo: servilo dove supportato, gestisci il fallback con eleganza altrove, e mantieni la pipeline pronta per il momento in cui arriverà il supporto universale.