JPEG XL et Core Web Vitals : ce que vous devez savoir maintenant que Chrome le prend en charge

Le JPEG XL revient enfin dans Chrome

Après trois ans de controverse, le JPEG XL est de retour dans Chromium. Chrome 145, sorti début février 2026, intègre un décodeur JPEG XL. Toujours caché derrière un flag (une option expérimentale), mais présent de manière fonctionnelle dans la base de code pour la première fois depuis son retrait controversé fin 2022. C'est important car le JPEG XL est manifestement supérieur à tous les formats d'image web actuels dans la plupart des dimensions techniques : 50 à 60 % plus petit que le JPEG, 10 à 15 % de meilleure compression que l'AVIF à des vitesses d'encodage équivalentes, et le seul format moderne avec un véritable décodage progressif. Pour les professionnels de la performance web, la trajectoire du format, de norme ISO à l'exil de Chrome puis à sa résurrection, représente à la fois une opportunité technique et une mise en garde sur le pouvoir des éditeurs de navigateurs sur la plateforme web.

Dernière révision par Arjen Karel en Février 2026

La prise en charge par les navigateurs en février 2026 n'est que de 12 %

La prise en charge globale effective du JPEG XL par les navigateurs se situe à environ 12 %, provenant presque entièrement des utilisateurs de Safari. Ce chiffre est sur le point de changer. Mais le calendrier reste incertain.

Safari 17+ (sorti en septembre 2023) fournit un décodage natif du JPEG XL sur macOS Sonoma, iOS 17, iPadOS 17, watchOS et visionOS. L'implémentation d'Apple délègue le décodage au framework d'image au niveau du système d'exploitation, ce qui signifie qu'il fonctionne partout où Safari s'exécute. Cependant, la prise en charge de Safari est explicitement partielle : pas de prise en charge de l'animation ni de décodage progressif. Deux des caractéristiques les plus distinctives du JPEG XL. Il s'agit d'une limitation significative qui réduit la proposition de valeur globale du format sur les appareils Apple.

Chrome 145 (février 2026) réintroduit le JPEG XL via un décodeur pur Rust appelé jxl-rs, remplaçant l'implémentation précédente C++ libjxl. Le décodeur est masqué derrière chrome://flags/#enable-jxl-image-format et n'est pas activé par défaut. Google a défini des conditions claires pour l'activation par défaut : un engagement pour une maintenance à long terme et le respect des critères de lancement standard. Le décodeur Rust fonctionne actuellement à 15 à 25 % de la vitesse de l'implémentation de référence C++, avec 26 PR (Pull Requests) d'optimisation fusionnées rien qu'en décembre 2025. Les capacités confirmées comme fonctionnelles incluent les profils colorimétriques ICC, les animations, l'alpha/transparence, le wide gamut (Display P3) et le HDR (PQ/HLG).

Pour essayer le JPEG XL dans Chrome aujourd'hui, accédez à chrome://flags/#enable-jxl-image-format et réglez-le sur "Enabled" (Activé). Redémarrez Chrome. Tout site diffusant déjà des images JXL (les clients Cloudinary, par exemple) commencera à les fournir à votre navigateur.

Firefox reste le plus en retard. Le format n'est disponible que dans Firefox Nightly derrière l'option image.jxl.enabled. Point critique, le code du décodeur n'est pas du tout compilé dans les versions stables, le flag ne fait donc rien sur la version publique de Firefox. La position de Mozilla est passée de "négative" à "neutre". Le décodeur Rust jxl-rs a été intégré à Firefox Nightly (ciblant Firefox 149), mais six points bloquants subsistent avant qu'il puisse être publié en version stable : prise en charge du profil colorimétrique, décodage progressif, HDR, intégration du profileur, compilation dans les versions de sortie et validation des Web Platform Tests. Aucun calendrier n'existe pour la prise en charge stable.

Edge, en tant que dérivé de Chromium, contient probablement le code jxl-rs de Chrome 145, mais n'a pas officiellement annoncé ni documenté la prise en charge du JPEG XL. Les notes de mise à jour d'Edge 145 n'en font aucune mention.

Interop 2026 a inclus le JPEG XL comme zone d'investigation (et non comme zone de concentration complète), avec la participation d'Apple, Google, Microsoft et Mozilla. Cela signale une intention inter-fournisseurs de créer des suites de tests complètes, ce qui précède généralement un déploiement plus large.

Comment le JPEG XL surpasse toutes les alternatives. Et où il ne le fait pas

L'histoire de l'efficacité de la compression est nuancée et dépend fortement du type de contenu et du débit binaire. Au niveau le plus élevé, le JPEG XL remporte les comparaisons réelles les plus importantes.

Face au JPEG

Les gains sont spectaculaires. Le JPEG XL atteint une qualité visuellement sans perte à environ 1,2 bit par pixel là où le JPEG nécessite 2,4 bpp. Une amélioration du simple au double. L'évaluation de DebugBear d'une photographie de 990 Ko a montré que le JPEG XL était à 472 Ko (52 % d'économie), contre 700 Ko pour le WebP et 507 Ko pour l'AVIF. Les tests de Cloudinary sur plus de 40 000 images ont révélé que le JPEG XL avec un effort de 6 produisait des fichiers 20 % plus petits que l'AVIF tout en s'encodant 2,5 fois plus vite.

Face à l'AVIF

La comparaison dépend du débit binaire (bitrate). À des débits faibles inférieurs à 0,4 bpp (forte compression), l'AVIF surpasse le JPEG XL. Il produit des images plus lisses avec moins d'artefacts. À des débits moyens à élevés (0,4 bpp et plus), où se trouve la plupart de la photographie web, le JPEG XL gagne systématiquement sur la préservation des détails et la fidélité. La propre étude comparative d'AVIF de Google a montré que 9 des 13 métriques de qualité favorisaient le JPEG XL à des paramètres de vitesse d'encodeur pratiques. L'écart de vitesse d'encodage est énorme : l'AVIF (via libaom) est un ordre de grandeur plus lent que le JPEG XL en encodage mono-thread. Aux réglages les plus lents de l'AVIF (~0,5 Mpx/s), il correspond à la densité de compression du deuxième paramètre le plus rapide du JPEG XL à 52 Mpx/s. Une différence de vitesse de 100x.

Face au WebP

Le JPEG XL l'emporte de manière décisive. Le WebP est limité à une profondeur de couleur de 8 bits, à un sous-échantillonnage de chrominance (chroma subsampling) 4:2:0 en mode avec perte (lossy), et à une résolution maximale de 16 383 x 16 383 pixels. Le JPEG XL prend en charge jusqu'à 32 bits par canal (entier ou virgule flottante), des résolutions dépassant 1 milliard de pixels par côté, et n'a aucune contrainte de sous-échantillonnage de chrominance.

Le type de contenu est important

Pour des types de contenu spécifiques, les tests de DebugBear ont révélé un tableau plus mitigé. L'AVIF a gagné sur les logos (2 Ko contre 6 Ko pour le JXL) et les images avec transparence (18 Ko contre 63 Ko), tandis que le JPEG XL a gagné sur les photographies (472 Ko contre 507 Ko) et le contenu animé où il a atteint 99 % de compression (14 Ko à partir d'un GIF de 1,3 Mo, contre 56 Ko pour l'AVIF). Ces résultats ont utilisé les paramètres par défaut de Cloudinary, ils représentent donc des sorties typiques plutôt qu'optimisées.

Comparaison des fonctionnalités

Deux fonctionnalités qu'aucun autre format ne peut égaler

Les fonctionnalités les plus importantes sur le plan stratégique du JPEG XL sont le décodage progressif et le transcodage JPEG sans perte. Aucun concurrent n'offre ni l'un ni l'autre.

Décodage progressif

Le décodage progressif modifie fondamentalement la façon dont les images se chargent. Les fichiers JPEG XL sont toujours au moins progressifs 8x8 ; la trame DC (basse fréquence) est toujours encodée en premier. Avec seulement ~1 % des données de fichier téléchargées, un aperçu complet et utilisable de l'image apparaît. Comparez cela au JPEG progressif, qui nécessite 10 à 15 % pour son premier passage. Plus important encore, le JPEG XL prend en charge la progression ordonnée par la saillance (saliency) : des modèles d'apprentissage automatique (machine learning) peuvent identifier les régions visuellement les plus importantes (les visages dans les portraits, les détails des produits dans le e-commerce) et encoder ces régions pour qu'elles arrivent en premier. Le décodeur lisse les limites entre les régions terminées et celles encore en cours de chargement.

Cela crée une chronologie de rendu différente. L'AVIF nécessite l'image compressée complète avant que le décodage puisse commencer : le temps total est égal au temps de téléchargement plus le temps de décodage, séquentiellement. Le JPEG XL superpose le transfert et le décodage, de sorte que l'utilisateur voit un contenu significatif beaucoup plus tôt. Cloudinary a noté que le rendu progressif du JPEG XL élimine le besoin de fichiers séparés pour les images de remplacement de basse qualité (LQIP, Low Quality Image Placeholder), supprimant ainsi complètement les octets redondants. Cependant, il convient de noter que l'implémentation actuelle de Safari ne prend pas en charge le décodage progressif, ce qui limite cet avantage aux futures implémentations de Chrome et Firefox.

Transcodage JPEG sans perte

Le transcodage JPEG sans perte est la fonctionnalité secrète du JPEG XL. Le format peut copier directement les coefficients de bloc DCT du JPEG dans ses propres blocs VarDCT, n'améliorant que le codage entropique. Le résultat : ~20 % de réduction de taille de fichier en moyenne (fourchette : 13 à 22 %) avec le fichier JPEG original reconstructible bit pour bit à partir du fichier JXL. Aucun autre format ne peut faire cela. Le transcodage vers WebP ou AVIF nécessite un décodage en pixels et un ré-encodage, provoquant une perte générationnelle. L'API DICOM de Google Cloud Platform utilise déjà cette capacité pour réduire de 20 % la taille des fichiers d'imagerie médicale.

À l'échelle du Web, si tous les JPEG actuels étaient transcodés sans perte en JXL, les économies de bande passante seraient énormes. La communauté JPEG XL estime que les économies d'énergie équivaudraient à alimenter ~487 000 foyers américains pendant une heure par jour.

Ce que cela signifie pour les Core Web Vitals

Le JPEG XL affecte chaque métrique des Core Web Vitals par le biais de mécanismes différents, et la relation est plus nuancée que "des fichiers plus petits = de meilleurs scores".

LCP (Largest Contentful Paint)

Le LCP bénéficie de deux effets cumulatifs. Premièrement, des tailles de fichiers plus petites réduisent la Resource Load Duration. La phase de téléchargement. Une réduction de 52 % par rapport au JPEG signifie que l'image de héros (hero image) arrive environ deux fois plus vite sur les connexions à bande passante restreinte. Deuxièmement, le JPEG XL décode plus vite que l'AVIF, réduisant l'Element Render Delay. Le décodage complexe de l'AVIF, dérivé d'un codec vidéo, peut créer une surcharge significative du CPU sur les appareils mobiles, où un AVIF plus petit qui se télécharge plus rapidement peut être partiellement annulé par un temps de décodage plus long. La vitesse de décodage du JPEG XL allant jusqu'à 132 Mpx/s et l'optimisation SIMD minimisent ce goulot d'étranglement. Cependant, le LCP est mesuré lorsque l'image est entièrement rendue, de sorte que le décodage progressif n'améliore pas directement l'horodatage du LCP. Il améliore les performances perçues, ce qui compte pour la user experience même s'il ne fait pas bouger la métrique. Si le JPEG XL est le format de votre image LCP, préchargez-le (preload) afin que le navigateur le découvre le plus tôt possible.

CLS (Cumulative Layout Shift)

Le CLS ne se soucie pas du format. Tous les formats bénéficient de la même manière d'attributs de largeur et de hauteur explicites. Le JPEG XL encode effectivement les informations de dimension dans les en-têtes initiaux, ce qui pourrait théoriquement aider les navigateurs à allouer de l'espace plus rapidement, mais l'impact pratique est négligeable par rapport au simple paramétrage des dimensions en HTML.

INP (Interaction to Next Paint)

L'INP peut être affecté par un décodage d'image lourd sur le main thread (fil d'exécution principal). Le décodage plus rapide et l'optimisation SIMD du JPEG XL signifient moins de blocage du main thread que l'AVIF, bien que les deux formats soient généralement décodés hors du main thread dans les navigateurs modernes.

Impact dans le monde réel

Selon le Web Almanac 2025, le JPEG représente toujours 57 % des images LCP sur mobile et sur ordinateur de bureau. Le WebP a atteint 11 %, soit une hausse de 4 points de pourcentage par rapport à 2024. L'AVIF ne se situe qu'à 0,7 %. Le JPEG XL n'est même pas encore mesuré. La page web médiane charge 19 images sur mobile pesant 911 Ko au total. Les convertir de JPEG en JPEG XL permettrait d'économiser environ 450 à 550 Ko par page. À un poids d'image médian sur ordinateur de bureau de 1 058 Ko, les économies approchent de 500 à 630 Ko.

Sur les sites surveillés par CoreDash, les pages diffusant des images dans des formats modernes (AVIF ou WebP) affichent des taux de "bon" LCP de 81 %, comparativement à 64 % pour les pages s'appuyant encore uniquement sur le JPEG. Au fur et à mesure que le JPEG XL bénéficiera d'une prise en charge plus large des navigateurs, l'écart devrait encore se creuser. Surveiller vos données de Real User Monitoring après l'activation de la diffusion JXL vous dira exactement combien les utilisateurs réels en bénéficient.

Servir du JPEG XL aujourd'hui avec des alternatives (fallbacks) appropriées

La mise en œuvre nécessite une stratégie en plusieurs couches : l'élément <picture> pour les images HTML, la négociation de contenu côté serveur pour le CSS et les images référencées dynamiquement, et l'automatisation via CDN là où elle est disponible.

L'élément picture

L'élément <picture> offre l'approche côté client la plus propre. Les navigateurs évaluent les éléments <source> de haut en bas et utilisent le premier format pris en charge :

<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="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Si cette image est votre hero et l'élément LCP probable, supprimez loading="lazy" et réglez sa fetchpriority sur high. Ne mettez jamais en chargement lent (lazy load) votre image LCP.

Pour les images responsives, chaque source a besoin de son propre srcset avec des descripteurs de largeur. Créant une explosion combinatoire de 12+ variantes par image (3 ou 4 formats x 3 ou 4 tailles). C'est là que l'automatisation via CDN devient essentielle.

Négociation de contenu côté serveur

La négociation de contenu côté serveur inspecte l'en-tête Accept. Safari 17+ envoie image/jxl dans son en-tête Accept. La configuration Nginx associe cela aux extensions de fichiers :

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

Le détail critique : incluez toujours Vary: Accept dans l'en-tête de réponse afin que les CDN et les caches proxy stockent des variantes séparées par format. Sans cela, une réponse JXL mise en cache sera servie aux navigateurs qui ne peuvent pas la décoder.

Prise en charge par les CDN

La prise en charge par les CDN est inégale. Cloudinary offre une prise en charge complète du JPEG XL via son paramètre f_auto. Rien de surprenant étant donné que Cloudinary a co-créé le format et livre déjà environ 1 milliard d'images JPEG XL par jour. L'Image Optimizer de Fastly a ajouté une prise en charge complète du JPEG XL en juillet 2024, en utilisant l'effort d'encodage 3 avec 4 threads et en revendiquant une économie d'environ 60 % par rapport au JPEG. Cloudflare, malgré une forte demande de la communauté, ne prend pas en charge la conversion JPEG XL dans son produit Image Resizing. Il peut mettre en cache les variantes JXL depuis votre origine via Vary: Accept, mais ne peut pas les générer. Si vous utilisez Cloudflare, consultez notre guide sur la configuration de Cloudflare pour les Core Web Vitals pour connaître les paramètres qui aident. AWS CloudFront, Akamai et Azure n'ont pas de prise en charge native du JPEG XL.

L'outillage

L'outillage pour générer des fichiers JPEG XL se concentre sur cjxl de l'implémentation de référence libjxl. Paramètres clés : -d pour la distance (0 = sans perte, 1.0 à 2.0 pour la qualité web avec perte), -e pour l'effort (1 à 9, défaut 7), et -p pour l'encodage progressif. Pour les entrées JPEG, cjxl input.jpg output.jxl effectue un transcodage sans perte par défaut. Le chemin de migration le plus simple possible. ImageMagick, libvips (depuis la 8.11), et Photoshop v25 prennent également en charge le JXL. Cependant, sharp (la bibliothèque d'images Node.js qui alimente Next.js) a une prise en charge expérimentale du JXL depuis la v0.31.3, mais les binaires précompilés distribués via npm n'incluent pas le codec JXL. Vous devriez compiler libvips vous-même avec la prise en charge de libjxl, et le mainteneur a fermé la demande pour des binaires JXL précompilés. Cela signifie que Next.js n'a pas de prise en charge pratique du JPEG XL clé en main. La prise en charge du noyau WordPress est suivie en tant que ticket #52788, mais le véritable point bloquant est que l'extension GD de PHP ne prend pas en charge le JPEG XL. PHP 8.5 (novembre 2025) manque toujours de prise en charge de GD pour le JXL.

La décision d'Halloween et son annulation trois ans plus tard

L'histoire politique du JPEG XL dans Chrome est une étude de cas sur le pouvoir des éditeurs de navigateurs sur les standards du Web. La comprendre est important car elle révèle les forces qui déterminent les technologies qui parviennent aux utilisateurs.

Le 31 octobre 2022, dans ce qui a rapidement été surnommé la "décision d'Halloween", Jim Bankoski de l'équipe Chrome de Google a annoncé la suppression du support expérimental du JPEG XL. Les raisons invoquées étaient au nombre de quatre : les options (flags) expérimentales ne devraient pas rester indéfiniment ; un intérêt insuffisant de l'écosystème ; des avantages incrémentiels insuffisants par rapport aux formats existants ; et la charge de maintenance. Bankoski a suggéré WebAssembly comme "une excellente voie à suivre" pour ceux qui voulaient le JPEG XL dans Chrome.

La réaction a été immédiate et soutenue. Le problème (issue) Chromium est devenu le deuxième plus étoilé de toute l'histoire du projet, avec plus de 1 000 votes positifs et des commentaires de représentants d'Intel, Adobe, Meta, Shopify, The Guardian, Flickr et la Fondation Krita. Jon Sneyers, co-créateur du JPEG XL chez Cloudinary, a publié une réfutation technique détaillée ("Le cas pour le JPEG XL") montrant que les tests de comparaison publiés par Google utilisaient des implémentations JPEG XL buggées et des métriques biaisées en faveur de l'AVIF. La Free Software Foundation a qualifié la décision de Google de preuve que Google Chrome était devenu l'arbitre des standards du web et a accusé l'entreprise d'agir pour ses propres intérêts. Puisque l'AVIF dérive de l'AV1, développé par l'Alliance for Open Media que Google a cofondée.

L'ironie n'a pas échappé aux observateurs : Google a lui-même co-créé le JPEG XL à travers son projet PIK, rendant la décision de le supprimer de Chrome d'autant plus confuse. Lorsque le JPEG XL a été proposé pour Interop 2024, il a reçu 646 réactions de la communauté. 4,5 fois la deuxième proposition en nombre de votes. Et a été rejeté avec pour seule explication un "manque de consensus".

Ce qui a finalement renversé la décision, c'est l'élan de l'écosystème qui a rendu l'absence de Chrome intenable. Apple livrant Safari 17 avec le support JPEG XL en septembre 2023 a été la première percée majeure. Mozilla passant de "négatif" à "neutre" puis à une volonté active d'implémenter (avec un décodeur Rust) a ajouté de la pression. L'Association PDF annonçant le JPEG XL comme le format HDR préféré pour le PDF en octobre 2025 a peut-être été le point de bascule. La visionneuse PDF intégrée de Chrome aurait besoin du support JXL pour rester conforme. Le 21 novembre 2025, Rick Byers (Architecte Technique Chrome) a posté le revirement, accueillant les contributions pour intégrer un décodeur JPEG XL performant et sûr en mémoire dans Chromium. En janvier 2026, le décodeur jxl-rs basé sur Rust a été fusionné, et Chrome 145 l'a livré derrière un flag en février 2026.

Conclusion : stockez des sources de qualité, convertissez à la demande

Le JPEG XL est techniquement le meilleur format d'image à usage général disponible. Meilleure compression que l'AVIF à des vitesses d'encodage pratiques, décodage progressif qu'aucun concurrent n'offre, et transcodage JPEG sans perte qui offre une économie instantanée de 20 % avec zéro perte de qualité. Les obstacles politiques qui ont bloqué son adoption pendant trois ans se dissolvent : Chrome a du code dans l'arborescence, Firefox intègre activement le même décodeur Rust, et Safari a livré le support depuis 2023.

La voie à suivre en pratique est de stocker le matériel source de la plus haute qualité possible et de laisser votre pipeline de distribution gérer la conversion de format. Conservez les PNG sans perte ou les JPEG maîtres de haute qualité comme originaux. Utilisez un CDN avec négociation automatique de format : le f_auto de Cloudinary, Fastly Image Optimizer ou Cloudflare Polish inspecteront l'en-tête Accept du navigateur et serviront du JXL, de l'AVIF, du WebP ou du JPEG sans que vous ayez à pré-générer une seule variante. Si vous auto-hébergez, configurez la conversion à la demande avec libvips ou ImageMagick derrière un cache côté serveur, en convertissant une fois par format à la première requête plutôt que de générer par lots quatre variantes par image à l'avance. Le transcodage sans perte du JPEG XL s'intègre parfaitement dans ce modèle : vos JPEG existants sont la source, et leur conversion en JXL est effectivement une conversion à la demande avec zéro perte de qualité. La question ouverte n'est pas de savoir si le JPEG XL obtiendra une large prise en charge par les navigateurs, mais quand Chrome basculera l'option (flag) de désactivé à activé par défaut. Et la seule réponse honnête est qu'aucun calendrier n'a été annoncé. L'exil de trois ans du format de Chrome devrait tempérer l'enthousiasme avec du pragmatisme : servez-le là où il est pris en charge, rabattez-vous gracieusement ailleurs, et laissez le CDN ou le pipeline de conversion gérer le reste.