JPEG XL vs AVIF : Quel format choisir pour la production ?

Pour la diffusion web en production en 2026, privilégiez AVIF : il offre une couverture mondiale d’environ 93 % des navigateurs à mi-2026, avec un support mature côté CDN, CMS et outils de build. JPEG XL est techniquement le format le plus performant — encodage plus rapide, lossless nettement supérieur, décodage progressif natif — mais Chrome le maintient toujours derrière un flag, ce qui limite JXL à environ 15 % de couverture, exclusivement via Safari, que caniuse classe comme support partiel. Ce seul constat tranche la question pour tout site public : tant que Chrome n’active pas JXL par défaut, une pile de diffusion JXL-first sert de toute façon AVIF ou JPEG à la grande majorité de vos utilisateurs.

Cet article répond directement au cas intermédiaire : vous servez déjà WebP ou AVIF, vous connaissez les limites de JPEG, et vous cherchez une décision défendable ancrée dans la réalité actuelle des navigateurs, non dans l’évangélisme de format. Il passe chaque critère en revue — compression, support navigateur, coût d’encodage, rendu progressif — vous fournit un snippet <picture> correct et vous indique le signal précis qui inverserait la recommandation.

Ce que sont réellement ces formats

AVIF et JPEG XL résolvent le même problème — des images plus légères à qualité égale ou supérieure — mais ils proviennent de lignées de conception opposées. AVIF (AV1 Image File Format) a été introduit par l’Alliance for Open Media en 2019 et dérive de l’intra-codage par image clé du codec vidéo AV1, utilisé par des services comme YouTube et Netflix. JPEG XL (ISO/IEC 18181) a été conçu spécifiquement comme format d’image fixe par le Joint Photographic Experts Group en collaboration avec Google et Cloudinary, et finalisé en tant que standard en 2022.

Cette différence de lignée — AVIF dérivé d’un codec vidéo, JPEG XL conçu spécifiquement pour les images fixes — explique la plupart des compromis évoqués ci-dessous. AVIF hérite de la puissante compression photographique avec pertes d’AV1 et de son encodeur gourmand en CPU. JPEG XL a été conçu autour de problématiques propres aux images : décodage progressif, couleur haute profondeur de bits, modes lossless, et une fonctionnalité qu’aucun autre format moderne ne propose — la recompression lossless de JPEG. Un JPEG existant peut être transcodé en JXL, réduisant la taille du fichier d’environ 20 %, et décodé pour retrouver le JPEG original octet par octet. Cela fait de JXL le seul format viable pour archiver de grandes bibliothèques JPEG sans perte de qualité — un critère de décision réel, pas une simple note de bas de page.

Compression : le vainqueur dépend du contenu

AVIF l’emporte sur la compression photographique avec pertes à qualité faible à moyenne ; JPEG XL l’emporte à haute qualité, sur les contenus non photographiques ou graphiques plats, et de manière décisive en lossless. Il n’existe pas de réponse universelle du type « X est N % plus petit », et tout article qui vous en donne une surestime un résultat qui dépend du contenu.

Le bilan pratique :

• Photographie avec pertes, qualité moyenne : La dégradation d’AVIF est plus douce et plus naturelle à des débits binaires agressifs — il floute les contours et masque les artefacts là où le mode VarDCT de JPEG XL peut produire des effets de sonnerie ou de blocage similaires au JPEG classique. C’est le terrain de prédilection d’AVIF et le cas web le plus courant.
• Haute qualité et contenu non photographique : JPEG XL égale ou surpasse AVIF, notamment sur les illustrations, logos, captures d’écran et graphiques riches en texte, où son mode d’encodage modulaire gère proprement les zones de couleur uniforme.
• Lossless : JPEG XL est nettement supérieur. Le lossless AVIF est peu pratique — il améliore à peine PNG — tandis que le JXL lossless est compétitif avec PNG et souvent bien plus compact.

Les taux de compression varient significativement selon le contenu et le réglage de qualité ; l’avantage de JXL sur AVIF est en particulier dépendant du contenu et ne constitue pas un chiffre établi. Avant d’engager une bibliothèque de contenu dans un format, testez vos assets spécifiques dans Squoosh, qui encode les deux formats dans le navigateur et affiche le compromis taille/qualité pour vos images plutôt que pour les benchmarks de quelqu’un d’autre.

Support navigateur : l’axe décisif

Le support navigateur est là où cette décision se prend réellement, et c’est l’axe que la plupart des articles de référence traitent mal ou rapportent avec des données obsolètes. À mi-2026, AVIF dispose d’environ 93 % de couverture mondiale et est activé par défaut dans Chrome, Edge, Firefox et Safari. JPEG XL se situe à environ 15 % de couverture — entièrement via Safari, et classé comme partiel.

L’historique de Chrome est important car deux des trois articles les plus cités le rapportent incorrectement. La chronologie exacte :

L’affirmation largement répandue selon laquelle Chrome aurait « abandonné » JPEG XL est désormais dépassée. Chromium a annulé la désignation obsolète du format et réintégré le décodage à l’aide d’un nouveau décodeur basé sur Rust plutôt que sur le libjxl en C++. Mais réintégration ne signifie pas livraison : sur le canal stable actuel, le décodage JXL dans Chrome reste désactivé par défaut et nécessite une activation manuelle via chrome://flags/#enable-jxl-image-format. Firefox intègre le code JXL dans Nightly derrière la préférence image.jxl.enabled, mais ne le compile pas dans les versions de production et n’a publié aucun calendrier de livraison.

La traduction en décision de déploiement est la partie que chaque article de référence sous-entend sans jamais l’énoncer clairement : un élément <picture> JXL-first sert aujourd’hui AVIF ou JPEG à environ 85 % de vos utilisateurs. Vous encodez et stockez trois variantes de format pour livrer JXL à environ un visiteur sur sept — et même cette portée n’est qu’un support partiel Safari. Tel est le coût réel d’une approche JXL-first aujourd’hui, et il ne se justifie qu’une fois que Chrome active le format par défaut.

Coût d’encodage et rendu progressif

JPEG XL s’encode plus rapidement qu’AVIF et supporte nativement le décodage progressif ; l’encodage AVIF est gourmand en CPU et ne dispose d’aucun véritable mode progressif. Ces deux différences sont opérationnellement pertinentes — l’une dans votre pipeline de build, l’autre dans le temps de chargement perçu par vos utilisateurs.

L’encodage AVIF est l’étape lente dans la plupart des pipelines

L’encodage AVIF avec l’encodeur de référence AV1 (libaom-av1) est l’étape la plus lente d’un pipeline d’images typique, nettement plus lente par image que JPEG XL à qualité perceptuelle équivalente. Pour une seule image hero convertie manuellement, c’est négligeable. Pour un job CI qui traite des centaines d’images produit à chaque déploiement, c’est une contrainte réelle : le temps d’encodage évolue proportionnellement au nombre d’images, et l’encodeur AV1 est coûteux en calcul par conception.

Mesures d’atténuation pratiques pour un pipeline Node.js :

• Utilisez Sharp, qui encapsule libvips, pour l’encodage AVIF et JXL. Il expose des contrôles quality et effort qui permettent d’arbitrer entre temps d’encodage et taille de sortie.
• Ajustez le paramètre effort/vitesse plutôt que d’exécuter l’encodeur au niveau d’effort maximal par défaut — un encodage AVIF à effort élevé produit des fichiers marginalement plus petits pour un coût en temps considérable.
• Parallélisez sur des threads de travail ou des cœurs CPU, ou déléguez la conversion à un CDN qui encode à la volée afin de ne jamais bloquer votre build.

const sharp = require("sharp");

// AVIF: lower `effort` trades a little size for much faster CI encoding
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL encodes faster at comparable quality (requires a libjxl-enabled build)
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

Vérifiez la disponibilité des formats dans votre build sharp installé avec sharp.format — le support JXL dépend du libvips/libjxl embarqué et n’est pas garanti dans toutes les distributions.

Le décodage progressif affecte le LCP perçu

JPEG XL supporte le décodage progressif natif : le navigateur affiche immédiatement une version basse qualité de l’image et l’affine au fur et à mesure de l’arrivée des données. AVIF ne dispose d’aucun véritable mode progressif, de sorte qu’une grande image AVIF s’affiche soit complètement, soit pas du tout. Sur des connexions lentes, cela se traduit par un délai visible du Largest Contentful Paint — l’emplacement de l’image hero reste vide jusqu’à l’arrivée du fichier complet.

C’est une classe de problème que nous observons directement dans les replays de session : sur les pages riches en images, l’emplacement d’une image hero reste vide pendant toute la durée du téléchargement d’une grande image sur une connexion contrainte, avec l’horodatage LCP ancré au moment où le fichier complet s’affiche enfin. Le décodage progressif à la manière de JXL répond exactement à ce mode de défaillance — une image basse qualité apparaissant rapidement et s’affinant progressivement — ce qui constitue le comportement de performance perçue qui compte pour les utilisateurs réels sur des réseaux lents, et la raison pour laquelle la taille de la charge utile et le rendu progressif sont des leviers LCP, non de simples préférences cosmétiques.

Le cadre de décision : livrez X si…

Livrez AVIF dès maintenant pour la production web publique, avec des fallbacks WebP et JPEG via <picture>. Recourez à JPEG XL dans des cas spécifiques et délimités : workflows lossless ou d’archivage, bibliothèques d’images non photographiques, audiences concentrées sur Safari, ou grandes archives JPEG à recompresser sans perte de qualité.

Livrez AVIF si :

• Vous gérez un site de production public nécessitant une large couverture aujourd’hui.
• Vos assets sont majoritairement photographiques ou mixtes.
• Vous utilisez un CMS ou un CDN avec support natif — AVIF est natif dans WordPress depuis WP 6.5 (avril 2024), et les principaux CDN l’encodent à la volée.
• Vous souhaitez des gains LCP mesurables par rapport à JPEG/WebP sans gérer une quatrième variante de format.

Recourez à JPEG XL si :

• Vous maintenez une grande archive JPEG et souhaitez une recompression lossless — transcodez en JXL (~20 % plus petit) et reconstituez les originaux octet par octet.
• Votre contenu est principalement non photographique : illustrations, logos, diagrammes, captures d’écran.
• Votre audience est majoritairement sur Safari et vous contrôlez l’intégralité du markup <picture> dans une configuration headless ou personnalisée.
• Vous construisez une diffusion tournée vers l’avenir pour le moment où Chrome activera JXL par défaut.

JPEG XL ne bénéficie d’aucun support d’upload natif dans WordPress à mi-2026, ce qui renforce AVIF comme choix CMS pratique.

Un snippet <picture> correct et à jour

Dans un élément <picture>, le navigateur évalue les entrées <source> dans l’ordre du document et sélectionne le premier type qu’il supporte, en se rabattant sur <img> si aucun ne correspond. L’ordre n’est donc pas cosmétique — c’est l’algorithme de sélection. Listez les formats du meilleur au moins bon selon votre priorité, et faites du fallback <img> un JPEG universellement supporté, pas un WebP (WebP nécessite sa propre entrée <source> car c’est un type MIME distinct).

<picture>
  <!-- JXL first: served only to Safari 17+ (partial); Chrome flagged-off in mid-2026 -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF: ~93% coverage, the workhorse tier for nearly all traffic -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: covers older Chrome/Firefox that predate AVIF -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: unconditional fallback; the src that always renders -->
  <img src="hero.jpg" alt="Description" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

Le constat honnête sur cette pile à quatre niveaux : aujourd’hui, elle vous coûte quatre variantes encodées pour livrer JXL à une minorité exclusivement Safari. Si votre audience n’est pas majoritairement sur Safari et que vous n’avez aucune raison d’archivage pour JXL, supprimez le premier <source> et livrez la version à trois niveaux AVIF/WebP/JPEG — elle couvre presque tout le trafic avec un format de moins à construire et stocker. Ajoutez la source JXL quand, et non avant que, Chrome bascule le flag.

Les signaux à surveiller pour que la recommandation change

Le déclencheur pratique pour faire de JPEG XL votre format de diffusion principal est l’activation par défaut de chrome://flags/#enable-jxl-image-format dans Chrome ; jusqu’à ce que cela se produise, le calcul de couverture — environ 15 % JXL (partiel Safari uniquement) contre ~93 % AVIF — maintient AVIF comme le seul format principal défendable pour la production web publique. Signaux concrets à surveiller :

• L’entrée Chrome Platform Status pour JPEG XL passant de « flagged » à « shipped/default-on ».
• La couverture full-support de caniuse.com/jpegxl franchissant un seuil utilisable et perdant sa désignation partielle.
• Firefox faisant passer JXL de Nightly à une version de production.
• Les principaux CDN activant par défaut la conversion JXL dans leurs pipelines d’images.

Lorsque le premier de ces signaux se concrétise, une pile <picture> JXL-first cesse d’être un coût spéculatif et devient la recommandation par défaut, et le cadre ci-dessus s’inverse.

Conclusion

Livrez AVIF aujourd’hui et gardez votre markup <picture> prêt pour JPEG XL. AVIF est le format qui atteint vos utilisateurs maintenant, avec les outils et le support CMS pour l’appuyer ; JPEG XL est le meilleur format sur le plan technique et le bon outil pour les archives lossless et la recompression JPEG, mais son cas pour le web public est entièrement conditionné à son activation par défaut dans Chrome. Convertissez vos assets en AVIF, ajoutez des fallbacks WebP et JPEG, et configurez une veille sur l’entrée Chrome Platform Status — le jour où ce flag s’active par défaut est le jour où il faudra reconsidérer JXL comme votre source principale.

FAQ

Servir AVIF et une source JXL dans le même élément picture double-t-il mon stockage et ma bande passante ?

Cela augmente le stockage, mais pas la bande passante par requête. Chaque variante de format que vous listez ajoute un fichier encodé à stocker, de sorte qu'une pile à quatre niveaux JXL, AVIF, WebP, JPEG signifie quatre fichiers stockés par image. La bande passante n'est pas affectée car le navigateur télécharge uniquement la première source supportée qu'il sélectionne, jamais plusieurs variantes simultanément. Le coût réel d'une pile JXL-first est l'encodage et le stockage supplémentaires pour atteindre une minorité Safari uniquement, pas des téléchargements dupliqués.

Puis-je convertir mes images AVIF en JPEG XL ultérieurement sans ré-encoder depuis l'original ?

Non, pas sans perte de qualité. Le transcodage lossless de JPEG XL est unique aux sources JPEG, pas AVIF ou WebP. Vous pouvez encapsuler un JPEG existant dans JXL et le reconstituer octet par octet, mais AVIF et WebP sont des formats avec pertes sans chemin de retour réversible équivalent. Convertir AVIF en JXL implique de décoder l'AVIF déjà compressé et de le ré-encoder, ce qui cumule les artefacts. Conservez toujours vos masters originaux lossless afin de pouvoir ré-encoder proprement vers n'importe quel format.

Pourquoi mon image hero AVIF nuit-elle encore au Largest Contentful Paint même si le fichier est plus petit que le JPEG ?

AVIF ne dispose d'aucun véritable décodage progressif, de sorte qu'une grande image AVIF ne s'affiche qu'une fois le fichier complet reçu, plutôt que d'afficher d'abord un aperçu basse qualité. Sur une connexion lente, l'emplacement hero reste vide pendant toute la durée du téléchargement, et l'horodatage LCP est ancré à l'affichage final. Une taille de fichier total plus petite ne modifie pas ce comportement tout-ou-rien. Le décodage progressif de JPEG XL s'affine de manière incrémentielle, ce qui améliore la charge perçue même à des tailles en octets similaires.

Un navigateur qui supporte à la fois AVIF et JPEG XL choisira-t-il la source que je liste en premier ?

Oui. L'élément picture sélectionne la première source dont l'attribut type est supporté par le navigateur, évalué dans l'ordre du document, indépendamment de la taille du fichier ou des capacités du format. Si vous listez JXL avant AVIF, une version de Safari supportant les deux servira JXL ; inversez l'ordre et il servira AVIF. Le navigateur ne compare ni la qualité ni le poids, donc l'ordre des sources est le mécanisme de sélection. Placez votre format préféré en premier et terminez par un fallback img JPEG universellement supporté.