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 in Chromium. Chrome 145, rilasciato all'inizio di febbraio 2026, include un decoder JPEG XL. Ancora dietro un flag, ma funzionalmente presente nella codebase 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 in quasi tutte le dimensioni tecniche: dal 50 al 60% più piccolo del JPEG, compressione migliore del 10-15% rispetto ad AVIF a parità di velocità di codifica, e l'unico formato moderno con decodifica progressiva reale. Per i professionisti delle web performance, la traiettoria del formato da standard ISO a esiliato da Chrome fino alla sua resurrezione rappresenta sia un'opportunità tecnica sia un monito sul potere dei vendor 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 intorno al 12%, quasi interamente da utenti Safari. Questo numero è destinato a cambiare. Ma la timeline 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 di sistema a livello di OS, il che significa che funziona ovunque Safari venga eseguito. 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 riduce la proposta di valore del formato sui dispositivi Apple.

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

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

Firefox rimane il più indietro. Il formato è disponibile solo in Firefox Nightly dietro il flag image.jxl.enabled. Fondamentalmente, il codice del decoder non è affatto compilato nelle build stabili, quindi il flag non fa nulla nella versione di rilascio di Firefox. La posizione di Mozilla è passata da "negativa" a "neutrale". Il decoder jxl-rs in Rust è arrivato in Firefox Nightly (puntando a Firefox 149), ma rimangono sei blocker prima che possa essere rilasciato in versione stabile: supporto per i profili colore, decodifica progressiva, HDR, integrazione del profiler, compilazione nelle build di rilascio e superamento dei Web Platform Tests. Non esiste una timeline per il supporto stabile.

Edge, come derivato di Chromium, probabilmente contiene il codice jxl-rs di 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 un'area di focus completa), con la partecipazione di Apple, Google, Microsoft e Mozilla. Ciò segnala l'intento cross-vendor di costruire suite di test complete, che solitamente precede il rilascio su più ampia scala.

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

La questione 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.

Rispetto al JPEG

I guadagni sono drammatici. JPEG XL raggiunge una qualità visivamente lossless a circa 1,2 bit per pixel dove il JPEG ne richiede 2,4 bpp. Un miglioramento di 2:1. Il benchmark di DebugBear di una fotografia da 990 KB ha mostrato JPEG XL a 472 KB (risparmio del 52%), 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 con effort 6 produce file più piccoli del 20% rispetto ad AVIF codificando 2,5 volte più velocemente.

Rispetto ad AVIF

Il confronto dipende dal bitrate. A bassi bitrate inferiori a 0,4 bpp (compressione pesante), AVIF supera JPEG XL. Produce immagini più levigate con meno artefatti. A bitrate medio-alti (0,4 bpp e oltre), dove si colloca la maggior parte della fotografia web, JPEG XL vince costantemente sulla conservazione dei dettagli e sulla fedeltà. Lo studio comparativo di Google su AVIF ha mostrato che 9 su 13 metriche di qualità favoriscono JPEG XL con impostazioni di velocità dell'encoder pratiche. Il divario di 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), raggiunge la densità di compressione della seconda impostazione più veloce di JPEG XL a 52 Mpx/s. Una differenza di velocità di 100 volte.

Rispetto a WebP

JPEG XL vince decisamente. WebP è limitato a una profondità di 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 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 rivelato un quadro più misto. 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 una GIF da 1,3 MB, contro i 56 KB di AVIF). Questi risultati hanno utilizzato le impostazioni predefinite di Cloudinary, quindi rappresentano output tipici piuttosto che ottimizzati.

Confronto delle funzionalità

Due caratteristiche che nessun altro formato può eguagliare

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

Decodifica progressiva

La decodifica progressiva cambia fondamentalmente il modo in cui le immagini vengono caricate. I file JPEG XL sono sempre progressivi almeno 8x8; il frame DC (bassa frequenza) viene sempre codificato per primo. Con solo lo ~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. 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 quelle regioni affinché arrivino per prime. Il decoder ammorbidisce i confini tra le regioni completate e quelle ancora in fase di caricamento.

Questo crea una timeline di rendering differente. AVIF richiede l'immagine compressa completa prima che la decodifica possa iniziare: il tempo totale è uguale 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 osservato che il rendering progressivo di JPEG XL elimina la necessità di file Low Quality Image Placeholder (LQIP) separati, rimuovendo interamente i byte ridondanti. Tuttavia, vale la pena notare 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 lossless

La transcodifica JPEG lossless è la funzionalità dormiente di JPEG XL. Il formato può copiare direttamente i coefficienti dei blocchi DCT del JPEG nei propri blocchi VarDCT, migliorando solo la codifica entropica. Il risultato: una riduzione media della dimensione del file del ~20% (range: 13-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 una perdita di generazione (generation loss). La DICOM API di Google Cloud Platform utilizza già questa capacità per ridurre del 20% le dimensioni dei file di imaging medico.

Su scala web, se tutti gli attuali JPEG fossero transcodificati senza perdita in JXL, il risparmio di larghezza di banda sarebbe enorme. La community JPEG XL stima un risparmio energetico equivalente ad alimentare ~487.000 case negli Stati Uniti per un'ora al giorno.

Cosa significa per i Core Web Vitals

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

LCP (Largest Contentful Paint)

LCP beneficia di due effetti combinati. In primo luogo, le dimensioni dei file più piccole riducono la Resource Load Duration. La fase di download. Una riduzione del 52% rispetto al JPEG significa che la hero image arriva circa due volte più velocemente su connessioni con larghezza di banda limitata. In secondo luogo, JPEG XL decodifica più velocemente di AVIF, riducendo l' Element Render Delay. La decodifica di AVIF, derivata da un complesso codec video, può creare un significativo overhead della CPU sui dispositivi mobili, dove un AVIF più piccolo che 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 riducono al minimo questo collo di bottiglia. Tuttavia, l'LCP viene misurato quando l'immagine è completamente renderizzata, quindi la decodifica progressiva non migliora direttamente il timestamp dell'LCP. Migliora le prestazioni percepite, che contano per l'esperienza dell'utente anche se non spostano la metrica. Se JPEG XL è il formato della tua immagine LCP, precaricala in modo che le browser la scopra il prima possibile.

CLS (Cumulative Layout Shift)

CLS non si cura del formato. Tutti i formati beneficiano ugualmente degli attributi espliciti di larghezza e altezza. JPEG XL codifica le informazioni sulle dimensioni negli header iniziali, il che teoricamente potrebbe aiutare i browser ad allocare lo spazio più velocemente, ma l'impatto pratico è trascurabile rispetto al semplice inserimento delle dimensioni nell'HTML.

INP (Interaction to Next Paint)

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

Impatto nel mondo reale

Secondo il Web Almanac 2025, il 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 solo allo 0,7%. JPEG XL non è ancora misurato. Una pagina web media carica 19 immagini su mobile con un peso totale di 911 KB. Convertirle da JPEG a JPEG XL farebbe risparmiare circa 450-550 KB per pagina. Con un peso medio 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 tassi di LCP "buoni" dell'81%, rispetto al 64% delle pagine che si affidano ancora esclusivamente al JPEG. Man mano che JPEG XL otterrà un supporto più ampio dai browser, il divario dovrebbe ampliarsi ulteriormente. Il monitoraggio dei tuoi dati di Real User Monitoring dopo aver abilitato la distribuzione JXL ti dirà esattamente quanto ne beneficiano gli utenti reali.

Servire JPEG XL oggi con i fallback corretti

L'implementazione richiede una strategia a più livelli: l'elemento <picture> per le immagini HTML, la negoziazione dei contenuti lato server per il CSS e le immagini referenziate dinamicamente, e l'automazione tramite CDN dove disponibile.

L'elemento picture

L'elemento <picture> fornisce l'approccio lato client 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>

Se questa immagine è la tua hero e il probabile elemento LCP, rimuovi loading="lazy" e imposta la sua fetchpriority su high. Non caricare mai in lazy load la tua immagine LCP.

Per le immagini responsive, ogni sorgente ha bisogno del proprio srcset con i 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 tramite CDN diventa essenziale.

Negoziazione dei contenuti lato server

La negoziazione dei contenuti lato server ispeziona l'header Accept. Safari 17+ invia image/jxl nel suo header Accept. La configurazione di 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 della risposta in modo che 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 dei CDN è disomogeneo. Cloudinary offre il supporto completo per JPEG XL tramite il suo parametro f_auto. Non sorprende, dato che Cloudinary ha co-creato il formato e distribuisce già circa 1 miliardo di immagini JPEG XL al giorno. L' Optimizer di immagini di Fastly ha aggiunto il supporto completo a JPEG XL a luglio 2024, utilizzando l'effort di codifica 3 con 4 thread e dichiarando un risparmio del ~60% rispetto al JPEG. Cloudflare, nonostante la forte richiesta della community, non supporta la conversione JPEG XL nel suo prodotto Image Resizing. Può memorizzare in cache le varianti JXL dal tuo origin tramite Vary: Accept, ma non può generarle. Se usi Cloudflare, consulta la nostra guida sulla configurazione di Cloudflare per i Core Web Vitals per le impostazioni che sono d'aiuto. AWS CloudFront, Akamai e Azure non hanno un supporto nativo per JPEG XL.

Strumentazione (Tooling)

La strumentazione per la generazione di file JPEG XL si concentra su cjxl dall' 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 codifica progressiva. Per gli input JPEG, cjxl input.jpg output.jxl esegue la transcodifica senza perdita per impostazione predefinita. Il percorso di migrazione più semplice possibile. Anche ImageMagick, libvips (dalla 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 dalla v0.31.3, ma i binari predefiniti distribuiti tramite npm non includono il codec JXL. Dovresti compilare libvips tu stesso con il supporto libjxl, e il manutentore ha chiuso la richiesta per binari JXL precompilati. Ciò significa che Next.js non ha un supporto pratico per JPEG XL out of the box. 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 suo ribaltamento 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 modellano quali tecnologie raggiungono gli utenti.

Il 31 ottobre 2022, in quella che fu presto soprannominata la "decisione di Halloween", Jim Bankoski del team Chrome di Google annunciò 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 suggerì WebAssembly come "un'ottima strada da seguire" per chi desiderava JPEG XL in Chrome.

La reazione fu immediata e sostenuta. Il problema su Chromium divenne il secondo più votato nell'intera storia del progetto, con oltre 1.000 upvote e commenti da rappresentanti di Intel, Adobe, Meta, Shopify, The Guardian, Flickr e la Krita Foundation. Jon Sneyers, il co-creatore di JPEG XL presso Cloudinary, pubblicò una dettagliata confutazione tecnica ("The Case for JPEG XL") mostrando che i test comparativi pubblicati da Google utilizzavano implementazioni JPEG XL buggate e metriche sbilanciate verso AVIF. La Free Software Foundation definì la decisione di Google una prova del fatto che Google Chrome fosse diventato l'arbitro degli standard web e accusò l'azienda di agire per i propri interessi. Poiché AVIF deriva da AV1, sviluppato dall'Alliance for Open Media di cui Google è co-fondatrice.

L'ironia non sfuggì agli osservatori: Google stessa ha co-creato JPEG XL attraverso il suo progetto PIK, rendendo la decisione di ucciderlo su Chrome ancora più confusa. Quando JPEG XL fu proposto per Interop 2024, ricevette 646 reazioni dalla community. 4,5 volte la seconda proposta classificata. E fu rifiutato con la sola spiegazione di "mancanza di consenso".

Ciò che alla fine ha ribaltato la decisione è stato lo slancio dell'ecosistema che ha reso insostenibile l'assenza di Chrome. Il rilascio di Safari 17 con il supporto JPEG XL da parte di Apple a settembre 2023 è stata la prima grande rottura. Mozilla, passando da "negativa" a "neutrale" e poi alla disponibilità attiva a implementare (con un decoder Rust), ha aggiunto pressione. L' annuncio della PDF Association di JPEG XL come formato HDR preferito per il 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 il ribaltamento, accogliendo contributi per integrare un decoder JPEG XL performante e sicuro per la memoria in Chromium. Entro gennaio 2026, il decoder jxl-rs basato su Rust è stato unito, e Chrome 145 lo ha rilasciato dietro un flag a febbraio 2026.

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

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

Il percorso pratico da seguire è archiviare il materiale sorgente della massima qualità possibile e lasciare che la tua pipeline di distribuzione gestisca la conversione del formato. Conserva PNG lossless o JPEG master di alta qualità come originali. Usa un CDN con negoziazione automatica del formato: Cloudinary f_auto, Fastly Image Optimizer 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 ti occupi del self-hosting, imposta la conversione on-demand con libvips o ImageMagick dietro una cache lato server, convertendo una volta per formato alla prima richiesta piuttosto che generare in batch quattro varianti per ogni immagine in anticipo. La transcodifica lossless di JPEG XL si adatta perfettamente a questo modello: i tuoi JPEG esistenti sono la sorgente, e convertirli in JXL è effettivamente una conversione on-demand con zero perdita di qualità. La domanda aperta non è se JPEG XL otterrà un ampio supporto dai browser, ma quando Chrome passerà il flag da off a on per impostazione predefinita. E l'unica risposta onesta è che non è stata annunciata alcuna timeline. L'esilio di tre anni del formato da Chrome dovrebbe temperare l'entusiasmo con il pragmatismo: servilo dove supportato, usa i fallback con grazia altrove, e lascia che il CDN o la pipeline di conversione si occupino del resto.