JPEG XL : le nouveau format pour améliorer votre web performance

Publié le par

Les formats gif/png/jpeg ont été les formats d’images employés sur tous les sites web depuis une génération.
Ces formats ont eu une longévité exceptionnelle, parce que leur support était (quasi) universel, et qu’ils offraient des compressions correctes pour qui savait les optimiser.

Depuis une dizaine d’années, les initiatives pour créer de nouveaux formats encore plus performants se sont succédées. On a eu le format vectoriel SVG, puis le format WebP et plus récemment, le format AVIF. L’idée derrière est d’exploiter les progrès des algorithmes de compression, et des performances des processeurs.

Le format JPEG XL (aussi appelé JXL en forme abrégée), a quant à luir connu des débuts un peu cahotiques. Surtout parce que les équipes du navigateur leader (Chrome) et de Google avaient décidé de ne pas supporter le format. Pourquoi ? Le principal motif invoqué était le manque d’adoption. Mais aussi des critiques techniques.

Le paradoxe, c’est que des personnes travaillant chez Chrome avaient participé à la définition du format. Chrome avait ajouté le format (mais utilisable en activant un flag) en avril 2021. Puis avait désactivé le support en décembre 2022.

Chrome emboîte le pas de ses concurrents et supporte le JPEG XL

Mais comme souvent Google et Chrome se sentent obligés de suivre les initiatives de leurs concurrents. Or Safari a annoncé fin 2025 que leur navigateur supportait le format. Mozilla a annoncé qu’ils allaient le supporter. Et la PDF Association a confirmaient qu’ils adoptaient le format également pour utilisation dans des docs Pdf. En novembre 2025, Rick Byers, tech lead de Chrome, a donc laissé entendre qu’ils allaient supporter ce format à nouveau.

C’est fait depuis le déploiement de Chrome 155, publié le 6 octobre 2026. Cette nouvelle version décode JPEG XL par défaut sur Windows, macOS, Linux et Android.

L’état du support navigateur à la fin octobre 2026 :

  • Chrome 155 et Firefox 158 : décodage par défaut, animation et affichage progressif compris
  • Safari 17 et suivants : support partiel depuis 2023, sans animation ni décodage progressif selon Can I Use
  • Edge : MDN et Can I Use donnent des informations contradictoires, à tester avant de déployer
Pour suivre l’adoption de JXL, le site CanIuse.com est un passage obligé. On peut s’attendre à ce que tout soirt vert dans quelques mois : https://caniuse.com/?search=jxl

L’intérêt du JXL : recompresser un stock de JPEG sans perte d’information

Le principal intérêt du format JPEG XL, c’est qu’il peut reprendre un fichier JPEG existant sans le décoder en pixels : il récupère les coefficients DCT (la transformée qui découpe l’image en blocs de 8 × 8 pixels, cœur de la compression JPEG) et les réencode avec un codage entropique plus efficace. Le fichier obtenu s’affiche à l’identique, et l’opération est réversible : on peut reconstruire le JPEG d’origine octet pour octet.

Les auteurs du format, dont Jon Sneyers (Cloudinary) et Jyrki Alakuijala (Google Research), annoncent un gain d’environ 20 % dans leur article de synthèse publié sur arXiv en 2025.

Une opération rapide, sans arbitrage de qualité

Le transcodage en Jpeg->JXL ne demande aucun réglage particulier (contrairement à la conversion en JPEG). Il n’y a ni curseur de qualité à choisir, ni contrôle visuel à faire, ni risque de perte d’informations.

Et le transcodage est hyper rapide : sur une machine de test (un seul cœur Xeon à 2,8 GHz), une image de 768 × 512 pixels se transcode en 13 à 26 millisecondes. Il faut 6 à 17 millisecondes pour reconstruire le JPEG d’origine.

Cette vitesse permet de changer l’architecture chargée de délivrer des images :

  • Un site peut stocker ses images en JPEG XL et reconstruire le JPEG à la volée pour les clients qui ne lisent pas le format, y compris les robots.
  • Un site peut aussi garder ses JPEG et générer en tâche de fond une copie .jxl réservée aux navigateurs compatibles. Dans les deux cas, l’archive d’origine reste intacte.

C’est là que l’écart avec AVIF est le plus net. Passer un stock de JPEG en AVIF impose un réencodage avec perte : il faut choisir une qualité, par image ou par lot, contrôler le résultat, et accepter une dégradation qui s’ajoute à celle du JPEG source. Sur un catalogue produit ou une archive photo, c’est ce contrôle qualité qui coûte, bien plus que le calcul.

JPEG XL contre AVIF : le gagnant dépend de la qualité visée et des objectifs de taille pour les fichiers images

Sur la compression avec perte, les chiffres publiés viennent presque tous des parties prenantes.

En décembre 2022, l’équipe AVIF de Google a publié un comparatif destiné à justifier le retrait de JPEG XL. Cloudinary, qui a co-conçu JPEG XL, y a répondu en contestant la méthode. Jon Sneyers estimait en 2022 JPEG XL environ 17 % plus compact qu’AVIF à qualité égale. Le site communautaire jpegxl.info avance jusqu’à 25 %, et Google annonce 30 à 50 % de gain par rapport à JPEG.

Nous avons donc mesuré nous-mêmes, sur les mêmes 24 images Kodak. Pour chaque image et chaque format, nous avons cherché le fichier le plus petit atteignant un score cible de SSIMULACRA2, la métrique de qualité perçue conçue par Jon Sneyers chez Cloudinary, donc par un co-auteur de JPEG XL. Sur son échelle, 70 correspond à une qualité moyenne-haute, 80 à une haute qualité, 90 à une dégradation quasi imperceptible. Les réglages sont ceux par défaut des bibliothèques : libjxl 0.12.0 en effort 7, libavif 1.4.2 en vitesse 6, JPEG progressif optimisé.

Score SSIMULACRA2 viséJPEGJPEG XLAVIFÉcart JPEG XL / AVIF
70 (moyenne-haute)1 381 Ko1 049 Ko957 KoAVIF plus léger de 9,6 %
80 (haute qualité)2 143 Ko1 605 Ko1 544 KoAVIF plus léger de 3,9 %
90 (quasi imperceptible)4 864 Ko3 099 Ko3 495 KoJPEG XL plus léger de 11,3 %

AVIF l’emporte sur 22 images sur 24 au score 70. JPEG XL l’emporte sur 21 images sur 24 au score 90. Les deux formats battent nettement JPEG, de 24 à 36 % pour JPEG XL. JPEG XL encode aussi deux fois plus vite : 183 millisecondes en médiane, contre 373 pour AVIF au score 70.

Pourquoi le JPEG XL est promis à un bel avenir

Le format JPEG XL présente 3 avantages supplémentaires qui ne sont pas assez mis en avant :

  • Le décodage progressif. Une image JPEG XL s’affiche en version floue dès les premiers octets reçus, puis se précise. AVIF n’a pas de vrai mode progressif : l’image apparaît entière ou pas du tout. Sur une connexion lente, cela pèse sur le LCP (Largest Contentful Paint, le temps d’affichage du plus grand élément visible), ou du moins sur sa perception, puisque Chrome retient pour le LCP l’image entièrement chargée. Safari ne gère pas encore ce mode.
  • Les grandes dimensions. JPEG XL accepte des images jusqu’à un téra-pixel, en un seul flux. AVIF hérite des contraintes d’un codec vidéo : libavif refuse par défaut les images de plus de 268 millions de pixels (16 384 × 16 384), et les très grands visuels doivent être découpés en tuiles assemblées dans le conteneur.
  • La profondeur de couleur et le sans-perte. JPEG XL code jusqu’à 32 bits par composante, contre 12 pour AVIF. En compression sans perte, il remplace le PNG avec des fichiers nettement plus petits, alors qu’AVIF sans perte fait à peine mieux que PNG.

Pour un site média ou e-commerce, le premier point est le plus concret. Les deux autres concernent surtout la photo professionnelle, l’imagerie médicale et l’archivage.

La simple conversion d’un Jpeg en JXL permet des gains de 40 à 50% sur la taille des fichiers images avec zéro perte de qualité !

Côté SEO : Google Search ne supporte pas le format mais ce n’est pas grave

Le 15 octobre 2026, John Mueller, Search Advocate chez Google, a précisé sur Bluesky que Google Images et les aperçus Discover ne prennent pas en charge le format.

Le navigateur de Google affiche donc des images que son moteur ne sait pas encore indexer.

JPEG XL mérite pourtant une place dans votre chaîne de production : il recompresse sans aucune perte vos stocks de JPEG, et il bat AVIF sur les images de haute qualité. Ce qu’il ne doit pas faire, c’est remplacer le fichier déclaré dans l’attribut src, dans og:image ou dans vos données structurées.

Le message de John Mueller était clair et concret : si vous voulez apparaître dans Google Images ou dans les aperçus Discover, JPEG XL doit être servi comme une source alternative, avec un format reconnu par Google en repli dans la balise img :

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="..." width="1200" height="800">
</picture>

Le risque vient surtout des automatismes. Un CDN ou un plugin qui convertit tout en .jxl peut aussi réécrire l’URL déclarée dans og:image ou dans le balisage schema.org, deux champs que les consignes Discover de Google citent comme influençant le choix de la vignette. Même chose pour les sitemaps d’images. Sur les sites qui vivent de Discover, une vignette illisible coûte des impressions immédiatement.

Le cas des CDN qui choisissent le format selon l’en-tête Accept du navigateur est moins problématique, tant que l’URL ne change pas. Selon le comparatif de TheImageCDN, Fastly Image Optimizer sert déjà JPEG XL en priorité sur AVIF quand le navigateur l’accepte, et Cloudinary le propose avec le paramètre f_jxl. Vérifiez dans ce cas que la réponse porte un en-tête Vary: Accept, sans quoi un cache intermédiaire peut servir un .jxl à un client qui ne le lit pas.

Dernier frein : WordPress refuse toujours l’upload de fichiers .jxl. Le ticket #52788, ouvert il y a cinq ans, est classé « maybelater ». Il faut passer par un filtre upload_mimes ou par un plugin.

Mais ce n’est pas grave : en pratique, un chantier webperf compatible SEO passera par :

  • une simple conversion des seuls jpegs existants en JPEG XL
  • le maintien des jpegs existants comme version indexables, la version jxl étant déclarée comme alternative

Et vous aurez le meilleur des deux mondes.

Pourquoi tester ce format aujourd’hui

Selon l’étude State of Web Vitals de corewebvitals.io (deuxième trimestre 2026, 111 716 sites dont l’image LCP est identifiée), 49,6 % des images LCP sont encore des JPEG, contre 6,1 % en AVIF. Le gisement d’économie se trouve donc d’abord dans le stock existant. C’est précisément là que JPEG XL n’a pas de concurrent : 9 à 23 % de poids en moins selon l’origine des fichiers, sans décision de qualité et sans risque de perte. En compression avec perte, en revanche, il ne détrône pas AVIF sur les images web de qualité moyenne.

Si vous voulez tester ce format, voici quelques règles d’or à respecter :

  1. Mesurez le gain sur votre propre stock. Prenez un échantillon de 50 à 100 JPEG, passez-les dans cjxl (le transcodage sans perte est le mode par défaut pour une entrée JPEG), et vérifiez la reconstruction avec djxl. Vos fichiers diront si vous êtes plus près de 10 % ou de 20 %.
  2. Ne mettez jamais un .jxl dans l’attribut src, dans og:image, dans le balisage schema.org ni dans un sitemap d’images. Auditez votre CDN et vos plugins avant de les laisser convertir.
  3. Choisissez l’ordre des sources selon la qualité visée. Le navigateur retient la première source qu’il sait lire. Pour les visuels très fins (zoom produit, photographie, illustrations), placez JPEG XL en premier. Pour les images web de qualité moyenne, laissez AVIF en tête.
  4. Contrôlez la négociation de contenu si votre CDN choisit le format selon l’en-tête Accept : présence de Vary: Accept, et format servi à Googlebot-Image.

Bibliographie

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. Découvrez comment les données de vos commentaires sont traitées.

Ce contenu vous a plu ?

Inscrivez-vous gratuitement à notre newsletter et recevez chaque semaine l'actualité du SEO, du GEO et de l'IA directement dans votre boîte email. Vous pouvez vous désabonner à tout moment !