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

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 sotto un flag, ma è funzionalmente presente nel codice per la prima volta dalla sua controversa rimozione a fine 2022. Questo è importante perché JPEG XL è dimostrabilmente superiore a qualsiasi formato immagine web esistente sotto la maggior parte delle dimensioni tecniche: dal 50 al 60% più piccolo di JPEG, con una compressione del 10-15% migliore rispetto ad AVIF a parità di velocità di codifica, ed è l'unico formato moderno con una vera decodifica progressiva. Per i professionisti delle performance web, la traiettoria di questo formato da standard ISO all'esilio da Chrome fino alla resurrezione rappresenta sia un'opportunità tecnica sia un monito sul potere dei produttori di browser sulla piattaforma web.

Ultima revisione di Arjen Karel a febbraio 2026

Il supporto dei browser a febbraio 2026 è solo del 12%

Il supporto globale effettivo dei browser per JPEG XL si attesta a circa il 12%, proveniente quasi interamente dagli utenti Safari. Questo numero sta per cambiare. Ma la tempistica rimane incerta.

Safari 17+ (rilasciato a settembre 2023) offre la decodifica nativa di JPEG XL su macOS Sonoma, iOS 17, iPadOS 17, watchOS e visionOS. L'implementazione di Apple delega la decodifica al framework di gestione delle immagini del sistema operativo, il che significa che funziona ovunque giri Safari. 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 indebolisce l'intera proposta di valore del formato sui dispositivi Apple.

Chrome 145 (febbraio 2026) reintroduce JPEG XL tramite un decoder scritto puramente in Rust chiamato jxl-rs, che sostituisce la precedente implementazione libjxl in C++. Il decoder è protetto dal flag chrome://flags/#enable-jxl-image-format e non è abilitato di default. Google ha stabilito condizioni chiare per l'abilitazione di default: un impegno per la manutenzione a lungo termine e il soddisfacimento dei criteri di lancio standard. Il decoder in Rust ha attualmente prestazioni inferiori del 15-25% rispetto alla velocità dell'implementazione di riferimento in C++, con ben 26 PR di ottimizzazione unite nel solo mese di dicembre 2025. Le funzionalità confermate e funzionanti includono i profili colore ICC, le animazioni, il canale alfa/trasparenza, il gamut ampio (Display P3) e l'HDR (PQ/HLG).

Per provare JPEG XL su Chrome oggi, vai su chrome://flags/#enable-jxl-image-format e impostalo su Abilitato (Enabled). Riavvia Chrome. Qualsiasi sito che serve già immagini JXL (i clienti Cloudinary, ad esempio) inizierà a inviarle al tuo browser.

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 viene compilato affatto nelle build stabili, quindi il flag non ha effetto sulla versione release di Firefox. La posizione di Mozilla è passata da "negativa" a "neutrale". Il decoder Rust jxl-rs è arrivato in Firefox Nightly (con l'obiettivo di Firefox 149), ma rimangono sei blocker prima del rilascio in versione stabile: supporto dei profili colore, decodifica progressiva, HDR, integrazione del profiler, compilazione nelle build release e superamento dei Web Platform Tests. Non esiste una tempistica per il supporto stabile.

Edge, come derivato di Chromium, contiene probabilmente il codice jxl-rs di Chrome 145, ma non ha annunciato o documentato ufficialmente il supporto a 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 principale), con la partecipazione di Apple, Google, Microsoft e Mozilla. Questo indica la volontà dei vari produttori di creare suite di test complete, il che di solito precede un rilascio su più ampia scala.

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

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

Contro JPEG

I vantaggi sono enormi. JPEG XL raggiunge una qualità visivamente lossless a circa 1,2 bit per pixel, dove JPEG 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 (risparmio del 52%), rispetto ai 700 KB di WebP e ai 507 KB di AVIF. I test di Cloudinary su più di 40.000 immagini hanno rilevato che JPEG XL a effort 6 produce file del 20% più piccoli di AVIF codificando 2,5x più velocemente.

Contro AVIF

Il confronto dipende dal bitrate. A bassi bitrate, inferiori a 0,4 bpp (compressione pesante), AVIF supera JPEG XL. Produce immagini più morbide e con meno artefatti. A bitrate medio-alti (da 0,4 bpp in su), dove si colloca la maggior parte delle foto sul web, JPEG XL vince costantemente in quanto a conservazione dei dettagli e fedeltà. Lo studio comparativo di Google su AVIF ha mostrato che 9 metriche di qualità su 13 favoriscono JPEG XL con 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 a thread singolo. Alle impostazioni più lente di AVIF (~0,5 Mpx/s), questo eguaglia la densità di compressione della seconda impostazione più veloce di JPEG XL a 52 Mpx/s. Una differenza di velocità di 100x.

Contro WebP

JPEG XL vince nettamente. WebP è limitato a una profondità colore a 8 bit, sottocampionamento della crominanza 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 in virgola mobile), risoluzioni superiori a 1 miliardo di pixel per lato e non ha vincoli di sottocampionamento della crominanza.

Il tipo di contenuto conta

Per tipi di contenuto specifici, i benchmark di DebugBear hanno mostrato 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 a partire da una GIF da 1,3 MB, contro i 56 KB di AVIF). Questi risultati utilizzano le impostazioni predefinite di Cloudinary, quindi rappresentano risultati tipici piuttosto che ottimizzati.

Confronto delle funzionalità

Due funzionalità che nessun altro formato può eguagliare

Le caratteristiche strategicamente più importanti di JPEG XL sono la decodifica progressiva e la transcodifica JPEG senza perdita. Nessun concorrente le offre.

Decodifica progressiva

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

Questo crea una sequenza temporale di rendering diversa. AVIF richiede l'immagine compressa completa prima di poter avviare la decodifica: il tempo totale equivale al tempo di download più il tempo di decodifica, in sequenza. JPEG XL sovrappone il trasferimento e la decodifica, permettendo all'utente di vedere contenuti significativi molto prima. Cloudinary ha osservato che il rendering progressivo di JPEG XL elimina la necessità di file LQIP separati, rimuovendo del tutto i byte ridondanti. Tuttavia, va notato che l'attuale implementazione di Safari non supporta la decodifica progressiva, il che limita questo vantaggio alle future implementazioni di Chrome e Firefox.

Transcodifica JPEG senza perdita

La transcodifica JPEG senza perdita è l'asso nella manica 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: una riduzione media del peso dei file di circa il 20% (in un intervallo tra il 13 e il 22%) con il file JPEG originale ricostruibile bit a bit dal file JXL. Nessun altro formato può farlo. La transcodifica verso WebP o AVIF richiede la decodifica in pixel e la successiva ricodifica, causando una perdita di generazione. La DICOM API di Google Cloud Platform utilizza già questa funzionalità per ridurre del 20% le dimensioni dei file di imaging medico.

Su scala web, se tutti i JPEG attuali fossero transcodificati senza perdita in JXL, il risparmio di banda sarebbe enorme. La community di JPEG XL stima un risparmio energetico equivalente a quello necessario per alimentare circa 487.000 case americane per un'ora al giorno.

Cosa significa questo per i Core Web Vitals

JPEG XL influenza ogni metrica dei Core Web Vitals attraverso meccanismi diversi, e la relazione è più complessa del semplice "file più piccoli = punteggi migliori".

LCP (Largest Contentful Paint)

LCP beneficia di due effetti combinati. Primo, il peso inferiore dei file riduce la durata del caricamento della risorsa, cioè la fase di download. Una riduzione del 52% rispetto a JPEG fa sì che la hero image arrivi circa due volte più velocemente sulle connessioni a banda limitata. Secondo, JPEG XL viene decodificato più velocemente di AVIF, riducendo il ritardo di rendering dell'elemento. La decodifica complessa di AVIF, derivata da codec video, può creare un sovraccarico significativo per la CPU sui dispositivi mobili: in questo caso, un file AVIF più piccolo e veloce da scaricare può essere parzialmente vanificato da tempi di decodifica più lunghi. La velocità di decodifica di JPEG XL fino a 132 Mpx/s e le ottimizzazioni SIMD riducono al minimo questo collo di bottiglia. Tuttavia, l'LCP viene misurato quando l'immagine è completamente renderizzata, so la decodifica progressiva non migliora direttamente il timestamp dell'LCP. Migliora però le performance percepite, che contano per la UX anche se non modificano il valore della metrica. Se JPEG XL è il formato dell'immagine per il tuo LCP, precaricala affinché il browser la scopra il prima possibile.

CLS (Cumulative Layout Shift)

Al CLS non importa del formato. Tutti i formati beneficiano allo stesso modo degli attributi width e height espliciti. JPEG XL codifica le informazioni sulle dimensioni nei primi header, il che teoricamente potrebbe aiutare i browser ad allocare lo spazio più rapidamente, ma l'impatto pratico è trascurabile rispetto al semplice inserimento delle dimensioni nell'HTML.

INP (Interaction to Next Paint)

L'INP può essere influenzato da una pesante decodifica delle immagini sul main thread. La decodifica più rapida di JPEG XL e le ottimizzazioni SIMD implicano un minore blocco del main thread rispetto ad AVIF, sebbene in genere entrambi i formati vengano decodificati fuori dal main thread nei browser moderni.

Impatto nel mondo reale

Secondo il Web Almanac 2025, JPEG rappresenta ancora il 57% delle immagini LCP sia su mobile che su desktop. WebP è cresciuto fino all'11%, con un aumento di 4 punti percentuali rispetto al 2024. AVIF si attesta ad appena lo 0,7%. JPEG XL non viene ancora misurato. La pagina web mediana carica 19 immagini su dispositivi mobili, per un peso totale di 911 KB. Convertirle da JPEG a JPEG XL farebbe risparmiare circa da 450 a 550 KB per pagina. Con un peso mediano delle immagini su desktop di 1.058 KB, il risparmio si avvicina a 500-630 KB.

Tra i siti monitorati da CoreDash, le pagine che servono immagini in formati moderni (AVIF o WebP) mostrano l'81% di LCP buono, rispetto al 64% delle pagine che si affidano ancora esclusivamente a JPEG. Man mano che JPEG XL otterrà un supporto più ampio dai browser, questo divario dovrebbe allargarsi ulteriormente. Monitorare i tuoi dati RUM dopo aver abilitato la distribuzione di JXL ti dirà esattamente quanto ne beneficiano gli utenti reali.

Servire JPEG XL oggi con i dovuti fallback

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

L'elemento picture

L'elemento <picture> offre 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.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Se questa immagine è la tua hero image e il probabile elemento LCP, rimuovi loading="lazy" e imposta il suo fetchpriority su high. Non applicare mai il lazy loading alla tua immagine LCP.

Per le immagini responsive, ogni sorgente ha bisogno del proprio srcset con i descrittori di larghezza. Questo crea un'esplosione combinatoria di oltre 12 varianti per immagine (3 o 4 formati x 3 o 4 dimensioni). È qui che l'automazione del 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 di Nginx mappa questo comportamento sulle estensioni dei file:

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

Il dettaglio fondamentale: includi sempre Vary: Accept nell'header di risposta, in modo che i CDN e le cache dei proxy memorizzino varianti separate per ciascun formato. Senza questo accorgimento, una risposta JXL memorizzata in cache verrebbe servita anche ai browser che non sanno decodificarla.

Supporto CDN

Il supporto CDN è disomogeneo. Cloudinary offre il supporto completo a JPEG XL tramite il parametro f_auto. Cosa non sorprendente, visto che Cloudinary ha co-creato il formato e distribuisce già circa 1 miliardo di immagini JPEG XL al giorno. Image Optimizer di Fastly ha aggiunto il supporto completo a JPEG XL a luglio 2024, utilizzando l'encoding effort 3 con 4 thread e dichiarando un risparmio di circa il 60% rispetto a JPEG. Cloudflare, nonostante la forte richiesta della community, non supporta la conversione in JPEG XL nel suo prodotto Image Resizing. Può memorizzare in cache le varianti JXL dal tuo server di origine tramite Vary: Accept, ma non può generarle. Se usi Cloudflare, consulta la nostra guida su come configurare Cloudflare per i Core Web Vitals per trovare le impostazioni che possono aiutarti. AWS CloudFront, Akamai e Azure non hanno un supporto nativo a JPEG XL.

Strumenti

Gli strumenti per la generazione di file JPEG XL fanno capo a cjxl dell'implementazione di riferimento libjxl. Parametri chiave: -d per la distanza (0 = lossless, da 1,0 a 2,0 per qualità web lossy), -e per l'effort (da 1 a 9, default 7) e -p per la decodifica progressiva. Per i file JPEG in input, cjxl input.jpg output.jxl esegue una 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 di immagini Node.js che alimenta Next.js) ha un supporto sperimentale per JXL a partire dalla versione v0.31.3, ma i binari precompilati distribuiti tramite npm non includono il codec JXL. Dovresti compilare autonomamente libvips con il supporto a libjxl, e il manutentore ha chiuso la richiesta per i binari precompilati di JXL. Questo significa che Next.js non ha un supporto pratico out-of-the-box per JPEG XL. Il supporto del core di WordPress è tracciato come ticket #52788, ma il vero ostacolo è che l'estensione GD di PHP non supporta JPEG XL. PHP 8.5 (novembre 2025) manca ancora del supporto GD per JXL.

La decisione di Halloween e il dietrofront dopo tre anni

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

Il 31 ottobre 2022, in quella che fu subito ribattezzata "la decisione di Halloween", Jim Bankoski del team di Google Chrome annunciò la rimozione del supporto sperimentale a JPEG XL. I motivi dichiarati 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 suggerì WebAssembly come "un'ottima strada da percorrere" per chi desiderava JPEG XL su Chrome.

La reazione negativa è stata immediata e sostenuta. L'issue di Chromium è diventata la seconda con più stelle nell'intera storia del progetto, con oltre 1.000 upvote e commenti da parte di esponenti di Intel, Adobe, Meta, Shopify, The Guardian, Flickr e della Krita Foundation. Jon Sneyers, co-creatore di JPEG XL presso Cloudinary, pubblicò una dettagliata replica tecnica ("The Case for JPEG XL") dimostrando che i test di confronto pubblicati da Google utilizzavano implementazioni di JPEG XL affette da bug e metriche sbilanciate a favore di AVIF. La Free Software Foundation definì la decisione di Google come la prova che Google Chrome fosse diventato l'arbitro degli standard web, e accusò l'azienda di agire per i propri interessi personali, 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 tramite il suo progetto PIK, rendendo la decisione di escluderlo da Chrome ancora più confusa. Quando JPEG XL è stato proposto per Interop 2024, ha ricevuto 646 reazioni della community, ovvero 4,5x rispetto alla seconda proposta più votata, ed è stato respinto con la sola motivazione della "mancanza di consenso".

Ciò che alla fine ha ribaltato la decisione è stato lo slancio dell'ecosistema, che ha reso insostenibile l'assenza da Chrome. Il rilascio di Safari 17 con il supporto a JPEG XL da parte di Apple a settembre 2023 è stato il primo vero strappo. Il passaggio di Mozilla da "negativo" a "neutrale", e poi all'effettiva volontà di implementazione (con un decoder in Rust), ha aumentato la pressione. L'annuncio della PDF Association in cui si indicava JPEG XL come formato HDR preferito per i PDF a ottobre 2025 potrebbe essere stato il punto di svolta. Il visualizzatore PDF integrato di Chrome avrebbe infatti avuto bisogno del supporto a JXL per rimanere conforme. Il 21 novembre 2025, Rick Byers (Chrome Architecture Tech Lead) ha pubblicato il dietrofront, accogliendo favorevolmente i contributi per integrare un decoder JPEG XL performante e memory-safe in Chromium. Entro gennaio 2026, il decoder jxl-rs basato su Rust è stato integrato e Chrome 145 lo ha rilasciato sotto un flag a febbraio 2026.

Conclusione: conserva sorgenti di qualità, converti on-demand

JPEG XL è tecnicamente il miglior formato di immagine per uso generale disponibile. Offre una compressione migliore rispetto ad AVIF a velocità di codifica pratiche, una decodifica progressiva che nessun concorrente offre e una transcodifica JPEG senza perdita che fornisce un risparmio istantaneo del 20% con zero perdite di qualità. Gli ostacoli politici che hanno bloccato la sua adozione per tre anni si stanno dissolvendo: Chrome ha il codice integrato, Firefox sta integrando attivamente lo stesso decoder Rust e Safari ha distribuito il supporto dal 2023.

La strada pratica da seguire è conservare il materiale sorgente alla massima qualità possibile e lasciare che sia la tua pipeline di distribuzione a gestire la conversione del formato. Conserva PNG senza perdita o master JPEG ad alta qualità come originali. Usa un CDN con content negotiation automatica del formato: f_auto di Cloudinary, Image Optimizer di Fastly o Cloudflare Polish ispezioneranno l'header Accept del browser e serviranno JXL, AVIF, WebP o JPEG senza che tu debba pre-generare una singola variante. Se fai self-hosting, configura la conversione on-demand con libvips o ImageMagick dietro una cache lato server, effettuando la conversione una sola volta per formato alla prima richiesta anziché generare in blocco quattro varianti per ogni immagine in anticipo. La transcodifica senza perdita di JPEG XL si adatta perfettamente a questo modello: i tuoi JPEG esistenti sono la sorgente, e convertirli in JXL è a tutti gli effetti una conversione on-demand con zero perdite di qualità. La questione aperta non è se JPEG XL otterrà un ampio supporto dai browser, ma quando Chrome attiverà il flag di default. E l'unica risposta onesta è che non è stata annunciata alcuna tempistica. L'esilio di tre anni del formato da Chrome dovrebbe temperare l'entusiasmo con il pragmatismo: servilo dove supportato, offri un fallback adeguato altrove e lascia che sia il CDN o la pipeline di conversione a gestire il resto.