Le 6 octobre 2026, Chrome 155 est passé en version stable avec une nouveauté qui n'en est pas une : le décodage natif des fichiers .jxl. Quatre ans plus tôt, presque jour pour jour, Google avait retiré le JPEG XL de Chromium en le jugeant sans avenir. Le navigateur le plus installé de la planète réinstalle donc aujourd'hui ce qu'il avait débranché — sans expliquer vraiment pourquoi.
2022 : l'enterrement, arguments à l'appui
Rappel de la séquence. En 2022, Google déprécie puis supprime le JPEG XL du navigateur. Les motifs, consignés par un ingénieur sur le suivi de bug Chromium, tiennent en quatre idées : pas assez d'intérêt de l'ensemble de l'écosystème, un avantage incrémental jugé insuffisant face aux formats existants, et une charge de maintenance à réduire. Le format, pourtant standardisé ISO/IEC 18181, disparaît. La formule fait mouche encore aujourd'hui : on ne tue pas un format en invoquant son manque d'intérêt quand on ne l'a jamais vraiment activé par défaut.
Trois ans plus tard, en novembre 2025, le revirement est officialisé. Rick Byers, côté Chrome, annonce que l'équipe accueille les contributions pour intégrer un décodeur « performant et memory-safe ». Les arguments ont changé de camp : Safari a livré son support, Firefox a revu sa position, les signaux développeurs s'accumulent, et le JPEG XL s'apprête à entrer dans le PDF.
Depuis la dernière évaluation du JPEG XL, Safari a livré son support et Firefox a revu sa position. — Rick Byers, équipe Chrome
Côté calendrier, Chrome 145 (février 2026) avait intégré le décodeur, mais derrière un flag expérimental. Chrome 155, en stable début octobre 2026, l'active pour tout le monde, sur Windows, macOS, Linux, Android et ChromeOS. La différence n'est pas cosmétique : c'est le passage du bac à sable au grand public.
Ce que ça change vraiment : l'image redevient un poste chiffré
Sur le papier, les promesses sont solides. Le billet de Google annonce 30 à 50 % de compression en plus que le JPEG, la compression sans perte, le transcodage sans perte des JPEG existants, le HDR (High Dynamic Range), le grand gamut colorimétrique, une profondeur de bits élevée, l'animation et le décodage progressif. Autrement dit : moins de ko pour la même image, ou plus de qualité pour le même poids.
La conséquence n'est pas esthétique, elle est budgétaire. Une image qui pèse un tiers de moins, c'est du LCP (Largest Contentful Paint) gagné sur mobile, un budget data allégé et une bande passante facturée en baisse. Pour une équipe qui vend de la performance ou du SEO technique, l'image cesse d'être un réglage de finition et redevient une ligne du budget.
- Tester AVIF et JPEG XL sur ses propres visuels, comme le recommande Google, plutôt que de trancher en théorie.
- Mesurer le LCP avant/après sur les pages les plus lourdes en images, pas sur une page d'accueil idéale.
- Surveiller la chaîne d'outils : CMS, CDN et pipeline de build doivent savoir générer et servir du .jxl.
- Se rappeler qu'un gain de compression se paie parfois en CPU de décodage : le vieux téléphone compte aussi.
Le piège : un décodeur livré n'est pas un format adopté
C'est ici que la lecture trop rapide se casse. Google a réécrit le décodeur en Rust, via l'implémentation jxl-rs, précisément parce qu'un décodeur d'images est l'une des surfaces d'attaque les plus exposées du navigateur. Le billet vante l'usage des instructions SIMD (Single Instruction, Multiple Data), un fuzzing poussé et une revue assistée par IA — mais Google ne publie aucun chiffre de performance comparatif. Choisir la sécurité mémoire plutôt que le C++ de référence est une décision défendable ; encore faut-il que le gain de vitesse suive au quotidien.
Une démo réussie ne fait pas un format adopté.
Et le vrai goulot n'est pas le navigateur. Il est dans l'outillage : panneaux d'administration de CMS, chaînes de build, CDN, outils de retouche, générateurs d'images responsives. Tant que ces maillons ne produisent pas de .jxl sans friction, l'image moderne restera un geste manuel. Google lui-même refuse de trancher : il conseille de tester AVIF et JPEG XL selon les visuels, ce qui est honnête — et révélateur. Deux formats concurrents, ce n'est pas un standard qui s'installe, c'est un choix de plus à arbitrer.
Qui gagne, qui perd
Les gagnants ne sont pas ceux qu'on cite d'ordinaire. Ce sont les usages à haute fidélité : archives photographiques, conversions sans perte de JPEG existants, chaînes de production qui veulent un format unique pour le HDR et l'animation. Les équipes performance, ensuite, qui récupèrent un levier chiffrable. Les perdants relatifs ? Le C++ de référence, doublé par une réécriture mémoire-safe. Et surtout le récit selon lequel une guerre des formats serait tranchée une fois pour toutes : voilà un dossier rouvert quatre ans après sa clôture annoncée.
Reste l'incertitude. On ne sait pas encore si le JPEG XL s'imposera dans les faits, ni si Google assumera publiquement son revirement. Mais la leçon dépasse le format : dans la performance web, rien n'est jamais définitivement réglé, et un arbitrage technique enterré peut très bien ressortir de terre. La seule posture tenable est de garder la question ouverte — et ses mesures à jour.
