Critique de JPEG XL : AVIF compresse désormais mieux

Gianni Rosato a publié le 13 septembre 2026 une critique technique détaillée de JPEG XL. Il soutient que les encodeurs AVIF actuels battent désormais JPEG XL sur toute la plage de qualité. Le moment compte pour quiconque diffuse des images sur le web, car Firefox 157 doit activer JPEG XL par défaut à la fin du mois de septembre.

JPEG XL est un format d'image normalisé en 2022 sous la référence ISO/IEC 18181. AVIF est le format concurrent, construit à partir du codec vidéo AV1. Tous deux visent des fichiers plus petits que JPEG à qualité visible égale.

Une précision avant les chiffres : Rosato travaille sur le format concurrent. Il écrit qu'il fait de la compression d'images, et qu'« en travaillant sur un encodeur AV1, Julio Barba et moi avons nettement fait progresser AVIF ». Il le déclare dans l'article lui-même. Cela ne rend pas ses mesures fausses. Cela signifie qu'aucune partie indépendante ne les a encore vérifiées.

Ce que l'article affirme

Rosato commence par reconnaître les qualités du format. « JPEG XL est un codec d'image techniquement impressionnant ; c'est un progrès net par rapport à JPEG », écrit-il. Sa critique porte sur JPEG XL face à AVIF, non face à JPEG.

En compression sans perte, il mesure JPEG XL environ 11,9 % plus petit que le WebP sans perte sur des contenus web réalistes. Il y voit un gain faible au regard du travail que le format exige. En compression avec perte, il rapporte que les encodeurs AVIF actuels obtiennent de meilleurs scores sur trois métriques perceptuelles : CVVDP, MS-SSIM et SSIMULACRA2. Ces métriques estiment à quel point deux images se ressemblent pour un humain, au lieu de compter les pixels modifiés. « AVIF domine maintenant toute la plage de fidélité », écrit-il.

Il nomme aussi des outils de compression absents de JPEG XL. Le format n'a pas de modes de prédiction directionnelle ni de filtre de déblocage en boucle. La prédiction directionnelle permet à un encodeur de prédire un bloc de pixels à partir de ses voisins selon un angle, ce qui aide sur les contours francs. Un filtre de déblocage lisse les coutures visibles entre blocs compressés. L'absence des deux limite le format sur les images non photographiques, comme les captures d'écran et les dessins au trait, selon lui.

La bombe de décodage

L'affirmation la plus tranchante porte sur le temps de décodage, pas sur la taille. Rosato décrit une image construite exprès, qu'il appelle prime wall. Elle pèse 1 918 octets, et son décodage a pris 17,43 secondes de temps utilisateur sur un M5 Pro. Il écrit que « l'image prime wall ne pèse que 1 918 octets, il va donc devenir trivial de bombarder en JXL les appareils peu puissants ».

C'est la forme d'un déni de service, pas une plainte sur la qualité. Un envoi de deux kilo-octets qui coûte plusieurs secondes de processeur pose problème à tout service qui décode les images envoyées par ses utilisateurs. Il attribue cette ouverture à la grande expressivité de la spécification JPEG XL. Certaines constructions sont licites et en même temps extrêmement lentes.

Il rapporte deux autres résultats sur le décodage. Dans ses tests, WebP se décode plus de 10 fois plus vite que JPEG XL. Le rendu progressif fonctionne aussi dans AVIF désormais, et c'était l'un des avantages restants les plus nets de JPEG XL.

Les deux camps ne mesurent pas la même référence

Le travail du projet JPEG XL lui-même complique le tableau de la vitesse. jxl-rs est le décodeur en Rust que le projet dit livré dans Chrome et dans Firefox. Son dépôt décrit l'objectif : une conformité complète à la spécification, avec une meilleure sûreté mémoire et de meilleures performances de décodage que libjxl, le logiciel de référence officiel en C++. Le projet indique que jxl-rs égale de près cette référence et la dépasse parfois, avec une empreinte mémoire plus faible.

Ces affirmations et celles de Rosato ne se heurtent pas directement. Il mesure JPEG XL face à WebP et AVIF. Le projet mesure son nouveau décodeur Rust face à son ancien décodeur C++. Un décodeur peut battre son prédécesseur et perdre quand même face à WebP. Lues ensemble, les deux décrivent de réels progrès de décodage qui n'ont pas encore comblé l'écart rapporté par Rosato.

Ce que cela signifie pour les développeurs

Ne changez pas de format sur la foi d'un seul article. Chaque chiffre ci-dessus vient du jeu de tests d'un seul auteur, et cet auteur travaille sur le format qui gagne sa comparaison. La bonne réaction est de mesurer vos propres images, car les résultats de compression varient beaucoup selon le contenu.

Trois choses valent la peine ce mois-ci. D'abord, encodez un échantillon réel de vos images de production en AVIF et en JPEG XL, et relevez les tailles à une qualité que vous livreriez vraiment. Ensuite, mesurez les temps de décodage sur un téléphone bon marché plutôt que sur votre portable. Enfin, si vous acceptez des envois d'images, posez une limite dure de temps et de mémoire sur le décodage, puis testez-la avec un fichier délibérément retors.

Ce troisième point se justifie que vous livriez JPEG XL ou non. Prime wall est un exemple JPEG XL, mais tout codec moderne a ses entrées pathologiques. Un chemin d'envoi sans budget de décodage est le vrai défaut.

Pour la plupart des sites, le conseil pratique n'a guère bougé depuis l'annonce de Mozilla. Utilisez AVIF pour les photos ordinaires, et JPEG XL là où le rendu progressif de très grandes images compte. Ce que cette critique ajoute, c'est une raison de retester ce second cas, car le rendu progressif d'AVIF n'est plus le point faible qu'il était.