Chrome avait dit « non ». Puis « non, vraiment non ». Et voilà que le JPEG XL revient dans Chromium. Quand le navigateur dominant commence à refaire de la place à un format d’image, le web entier retient son souffle.
Google a réintégré le décodage du JPEG XL dans la base de code Chromium, avec l’idée que cela finira par toucher Chrome et les autres navigateurs dérivés. Ce n’est pas un simple caprice de passionnés de photo, c’est un choix qui pèse sur la vitesse d’affichage et la consommation de données. Pour comprendre ce demi tour, il faut revenir à une réalité brutale : sans Chrome, un standard web peut vite tourner en rond.
Le retour en grande pompe d'un format snobé par Google
Le point clé est simple : Chromium sait à nouveau reconnaître, décoder et afficher des images JPEG XL, sans passer par une extension ou un module externe. TechRadar précise que l’intégration passe par le décodeur « JXLImageDecoder », branché dans la chaîne de rendu des images. Le travail inclut aussi la détection du format par signature et de la télémétrie, afin de mesurer le comportement en conditions réelles.
Autre détail qui compte dans un projet aussi sensible que Chromium : le décodage s’appuie sur jxl-rs, une bibliothèque en Rust, avec en toile de fond les inquiétudes récurrentes sur la sûreté mémoire des décodeurs d’images historiques. Di le JPEG XL excite autant les hébergeurs et les éditeurs, ce n’est pas pour le folklore. Le format promet des fichiers plus légers, les porte-étendards du format avançant une baisse d’environ 20% via la recompression de JPEG existants, sans perte de qualité. Il apporte aussi des briques modernes attendues : HDR, large gamme de couleurs, affichage progressif, compression avec ou sans perte.
Google n'est pas (encore) grand monarque du web
Ce retour n’est pas qu’un geste technique. C’est surtout l’aveu que le web n’a pas envie de choisir entre « qualité photo » et « pages rapides », et que les formats d’image restent un chantier vivant. La preuve : pendant que PNG se remet à jour après 22 ans, avec HDR et métadonnées EXIF officialisées, l’industrie montre qu’elle veut des formats mieux adaptés aux écrans et aux usages actuels.
Il y a aussi un contexte politique interne à Chrome. En 2022, la justification de Google tenait en quelques arguments classiques : intérêt jugé trop faible, gains jugés insuffisants, et fardeau de maintenance, avec l’idée de supprimer le code autour de Chrome 110 (ça remonte, hein ?). Sauf que, dans le même temps, des acteurs comme Intel, Adobe, Cloudinary, Meta ou Shopify contestaient cette lecture dans les discussions côté Chromium. Traduction : le problème n’était pas l’absence de demande, c’était l’absence d’un chemin de livraison acceptable pour Chromium.
Et ce chemin passe ici par deux signaux. D’abord, une implémentation présentée comme plus robuste grâce à Rust, ce qui parle immédiatement aux équipes sécurité. Ensuite, une dynamique d’écosystème qui devient difficile à ignorer : Il ya d'abord l’arrivée de la prise en charge côté Safari via WebKit, et nous avions déjà détaillé l’arrivée d’une extension JPEG XL sur Windows 11 24H2. Quand le système d’exploitation et un navigateur majeur commencent à s’aligner, Chrome peut continuer à faire la moue, mais il finit par payer la facture en compatibilité.
Reste une nuance : Google avance souvent avec deux jambes. D’un côté, on modernise l’existant, avec « Jpegli » pour mieux encoder en JPEG tout en gardant la compatibilité. De l’autre, on rouvre la porte à un successeur plus ambitieux, JPEG XL, qui vise directement la photo et la diffusion web. Autrement dit, ce retour n’enterre pas les autres formats, il évite juste un scénario idiot : celui où le web se prive d’une option crédible par pure inertie. La vraie question, maintenant, est simple : Chrome va-t-il assumer ce retour côté utilisateur, ou le laisser dans un placard « pour tests » encore des mois.
Source : Tech Radar
