XL-Converter est un utilitaire graphique pour convertir vos images en formats utilisables sur Internet. Outre les classiques JPEG et PNG il y a donc AVIF, WEBP et JPEG-XL. L’outil se veut ergonomique avec un minimum d’options pratiques. Par exemple on peut indiquer une dimension ou un poids maximum pour les images. À mes yeux, l’intérêt d’XL-Converter c’est surtout le format Jpeg. Pourquoi ? parce que ce format est loin d’être mort : tout en travaillant sur Jpeg-XL, les chercheurs suisses de Google ont développé un nouvel algorithme d’encodage du Jpeg classique, et cet algo est très performant.
Jpegli, le nouvel algo, tire son nom du jargon suisse, tout comme guetzli, butteraugli, etc. par la même équipe. Il est inclus dans la version 0.10 de la libjxl, la bibliothèque de référence pour Jpeg-XL (c’est normal il en réutilise du code). Et par là, il se retrouve l’encodeur Jpeg de XL-Converter.
Jpeg est un format de compression qui date des années 80. C’est grâce à lui qu’on voit le web en couleur. On a souvent tenté de le remplacer, il résiste. C’est normal, non content d’offrir un bon rapport qualité/poids, il y a belle lurette que nos puces décodent les images Jpeg en un éclair. Jpeg est donc efficace et rapide, sa compression avec perte n’enlève que des détails invisibles à nos yeux. Enfin il a des défauts quand même : pour gagner encore plus de poids, il gomme encore plus de détails et nous laisse des artefacts bien visibles, qui ressemblent à des saletés dans l’œil, celles qu’on découvre en regardant un mur blanc. En principe je ne vous apprends rien, vous êtes habitués à optimiser le poids de vos images sur Internet et vous savez jouer du curseur pour obtenir le meilleur compromis pour la meilleure image Jpeg possible (© Voltaire).
Nos accès Internet deviennent sans cesse plus rapides, la puissance et la Ram sur nos ordis augmentent de même, les nuisances énergétiques itou. Ça m’importe. Et même si les nuisances vous indiffèrent, vous vous êtes peut-être déjà retrouvé pris au piège d’une zone blanche, ou bien sur une île surpeuplée de touristes en été, ou bien dans un pays lointain aux prises avec un vieil ordi malmené par les débits inconstants et la lourdeur de votre site web préféré, bref dans ma peau. La situation est tout de même assez commune pour qu'un des critères majeurs de bon référencement des pages web sur Google soit le temps de chargement et d’affichage1.
Normalement vous savez qu’il y a plusieurs facteurs là-dedans, matériels, logiciel et humain. Humain, voilà ce qui nous intéresse. C’est l’humain qui fait l’effort de soigner son code, d’utiliser un format qui décompresse vite, de redimensionner ses images et de compresser suffisamment, en acceptant des pertes que l’autre internaute ne verra jamais sur un écran non calibré, salis par les doigts, sous un éclairage douteux et le plus souvent coloré (dans les villes).
Il y a quelques mois, je pensais vous décrire les merveilles de Mozjpeg : les premières versions de Webp n’avaient pas convaincu Mozilla qui avait proposé un nouvel algo et un nouvel outil, plutôt efficace. En remplaçant purement et simplement la libjpeg, les gains en compression était du même niveau que Webp (à l’époque), mais pour ceux qui aimaient jongler avec les paramètres2, les gains étaient et sont toujours bien meilleurs. Tout le monde n’étant pas imageo-technophile, les feignants pouvaient se contenter d’utiliser ImageOptim pour un résultat équivalent.
Aujourd’hui, même les feignants n’ont pas d’excuses : Jpegli est super simple à utiliser3, plus rapide et meilleur que Webp ou Avif, produit beaucoup moins d’artefacts classiques du Jpeg et se décode à la vitesse de l’éclair puisque c’est du Jpeg normal. Et au sein d’XL-Converter c’est de la balle.
Je n’ai rien de plus à dire. En attendant Jpeg-XL dans tous nos navigateurs, Jpeg à la sauce Jpegli c’est trop bon, mangez-en.
En apéritif, goûtez donc cette petite note du divin Jon Sneyers :
More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.
-
voir ce paragraphe dans la doc sur les Core Web Vitals de Google. ↩
-
les paramètres sont dans la source, use the force luke, read the code ↩
-
disons plutôt qu’il n’y a pas besoin d’autre paramètres que le niveau de compression pour être bien meilleur que Webp. ↩
Connexion
