Dal 6 ottobre Chrome decodifica il formato, ma Google Images e Discover non lo indicizzano

Chi gestisce cataloghi prodotto, creatività e librerie di immagini ha oggi davanti un dilemma concreto. Un formato che promette di alleggerire di circa il 20% gli archivi JPEG esistenti senza perdere qualità è decodificato nativamente da Chrome dallo scorso 6 ottobre. Chi lo adotta adesso, però, rischia che quelle immagini non compaiano in Google Images né come anteprime in Discover. A chiarirlo, la scorsa settimana, è stato John Mueller in un post pubblicato su Bluesky: «FWIW if you’re hoping to get images shown in Google Images & as previews in Discover, etc – JPEG-XL is currently not supported». Tradotto: se l’obiettivo è comparire in Google Images e nelle anteprime di Discover, JPEG XL per ora non è supportato. Due prodotti della stessa azienda, due risposte opposte.

Il browser dice sì, la ricerca dice no

Il paradosso è tutto interno a Google. Da una parte il blog ufficiale per sviluppatori di Chrome conferma che il browser supporta la decodifica dei file JPEG XL (.jxl) a partire da Chrome 155, con il rilascio avvenuto il 6 ottobre 2026. Dall’altra, la ricerca non ha ancora seguito: Google Images e Discover non visualizzano JPEG XL, né come risultato immagine né come anteprima.

Per chi lavora sulla performance, la distinzione non è teorica. Un’immagine che si carica più velocemente nel browser ma non viene indicizzata come immagine è un asset che lavora a metà: migliora l’esperienza sulla pagina, ma sparisce da due superfici che per molti siti generano traffico qualificato a costo zero. La domanda allora è legittima: se la stessa Google è divisa, perché questo formato merita attenzione?

Venti per cento senza toccare un pixel

La risposta sta in un numero. Secondo i sostenitori del formato, citati da un’analisi pubblicata da The Register, JXL può ricomprimere senza perdita le immagini JPEG già esistenti, riducendone le dimensioni del 20%. Il punto chiave è il “lossless JPEG transcoding”: la transcodifica permette di ridurre intere librerie di circa il 20% senza alcun cambiamento di qualità e senza dover ricodificare gli originali.

Per un e-commerce con decine di migliaia di schede prodotto, o per un team creativo che archivia anni di asset di campagna, questo significa un risparmio di banda e di storage che non richiede di rifare il lavoro fotografico né di riaprire i file sorgente. Non è una promessa di compressione aggressiva con artefatti visibili: è lo stesso pixel, in un contenitore più leggero. Ed è proprio questo che rende il formato interessante per chi misura il costo di ogni kilobyte servito.

Il percorso che ha portato il formato fin qui è stato lungo. JPEG XL è nato da uno sforzo che univa FLIF, il formato di Cloudinary, con PIK, frutto della ricerca interna di Google; lo sviluppo è partito nel 2019 e già nel 2021 il formato è diventato lo standard ISO/IEC 18181. Il passaggio più significativo riguarda però Chromium: Google ha aggiunto il supporto a JXL nella base di codice open source, invertendo la decisione presa nel 2022 di abbandonare la tecnologia. Sul fronte concorrenza, Apple era arrivata prima: come ricorda il blog Mozilla Hacks, Safari ha introdotto JPEG XL fin dal 2023, ma con un’implementazione priva di alcune funzionalità chiave del formato, come il rendering progressivo. Un risparmio misurabile, dunque, con un supporto browser in crescita. Ma che resta fuori dall’elenco dei formati accettati dalla ricerca di Google.

Cosa fare con i propri asset, oggi

Il vincolo operativo è scritto nero su bianco nella documentazione di Google Search sulle immagini: la ricerca supporta le immagini referenziate nell’attributo src del tag img nei formati BMP, GIF, JPEG, PNG, WebP, SVG e AVIF. JXL non c’è. Questa lista va trattata come un requisito di pianificazione, alla pari delle specifiche tecniche di una piattaforma pubblicitaria: se un asset deve generare visibilità in Images o in Discover, deve stare dentro quell’elenco.

Il trade-off va quindi messo sul tavolo in modo esplicito. Il risparmio del 20% ha valore dove conta soprattutto la velocità di caricamento nel browser: landing page di campagna, aree riservate, gallerie interne, pagine il cui traffico arriva da canali a pagamento o diretti e non dalla ricerca per immagini. Diverso il discorso per le schede prodotto e i contenuti editoriali che vivono di traffico organico visivo: lì il costo nascosto è la perdita di esposizione in due superfici gratuite, e nessun guadagno in banda lo compensa se quella visibilità sparisce.

C’è anche un tema di allocazione delle risorse tecniche. Introdurre JXL nella pipeline significa gestire più versioni dello stesso asset e decidere quale servire a chi. Per un team piccolo, il tempo di sviluppo speso oggi su un formato che la ricerca non legge potrebbe rendere di più altrove;
per chi ha già un’infrastruttura di immagini matura, sperimentare su un perimetro limitato è una scelta ragionevole.

Il quadro, in sintesi: il 20% di risparmio è reale, ma per chi dipende dal traffico visivo di Google non si può ancora incassare per intero. Conviene sperimentare JXL dove conta il caricamento nel browser e mantenere i formati supportati dalla ricerca dove contano visibilità e anteprime. Le fonti non indicano quando Images e Discover cambieranno posizione: quando succederà, sarà il momento di rivedere la decisione.