Les graphiques ne sont pas des photos : là où le lossless gagne

« Convertissez tout en AVIF » est un bon conseil pour les photographies et un mauvais conseil, discrètement, pour tout le reste. Une capture d’écran, un logo, un graphique, une maquette d’interface, un dessin au trait : ce sont des graphiques, pas des photos, et les codecs avec pertes qui rendent AVIF et JPEG si efficaces sur les photos sont le mauvais outil pour eux.

Pourquoi les codecs avec pertes échouent sur les graphiques

JPEG, WebP avec pertes et AVIF sont construits pour les photographies : dégradés doux, texture naturelle, pas d’arêtes nettes. Ils fonctionnent en jetant le détail haute fréquence que l’œil ne remarquera pas sur une photo. Pointez-les sur un graphique et ce même mécanisme se retourne contre vous :

• Du ringing sur les arêtes nettes. Le texte et les icônes ne sont rien d’autre que des arêtes nettes. Les transformations avec pertes étalent un halo de « bruit moustique » autour de chaque lettre : l’artefact pour lequel JPEG est connu depuis les années 1990, et qui survit dans les codecs modernes sur les arêtes nettes.
• Du banding sur les aplats de couleur. Un remplissage uni ou un dégradé propre est exactement ce que la quantification par blocs postérise en marches visibles.
• Vous payez pour flouter, puis vous payez encore. Pour masquer ces artefacts, vous poussez la qualité, et un codec avec pertes forcé au quasi-lossless sur un graphique est souvent plus lourd qu’un codec lossless conçu pour ça, tout en restant inexact.

Un graphique a peu de couleurs et une structure nette. Le bon réflexe, c’est de le garder exact et de compresser la redondance, pas de jeter du détail.

Les chiffres, sur de vrais graphiques

Nous avons fait passer le jeu de graphiques de notre benchmark (213 graphiques réels : logos, graphiques, interfaces, art en aplats) dans les outils conçus pour eux, en mesurant le gain par rapport au PNG d’origine :

Le WebP sans perte réduit ces graphiques d’environ moitié, et chaque pixel reste identique. oxipng réoptimise le PNG lui-même sans changer de format : sûr partout. pngquant va le plus loin en réduisant la palette ; sur de l’art en aplats, le résultat est visuellement indiscernable, sur une photo ce serait un désastre. Et c’est bien tout l’enjeu : l’outil doit correspondre au contenu.

La règle : classifier d’abord, compresser ensuite

L’erreur n’est pas de choisir WebP ou de choisir PNG. C’est de choisir un seul codec pour tout. Un pipeline qui livre bien des images web doit regarder chaque asset et décider ce qu’il est avant de décider comment le compresser :

• Photographie → AVIF/WebP avec pertes, qualité ciblée sur un score perceptuel (voir nos chiffres AVIF vs WebP vs JPEG).
• Graphique avec une zone photographique (une capture d’écran d’une photo) → la voie avec pertes peut encore l’emporter.
• Graphique en aplats, logo, graphique de données, dessin au trait → sans perte, et rester dans un format dont le graphique a réellement besoin.

C’est ce que fait Patu : il classifie chaque image et la route en conséquence. Un graphique reste sans perte, réencodé à l’identique, pas flouté dans un format avec pertes à la fois plus lourd et pire. Une photo reçoit la recherche avec pertes ciblée sur la qualité. Même point d’entrée, traitement opposé, parce que ce sont des problèmes opposés.

Le conseil de départ survit avec un mot ajouté : convertissez vos photos en AVIF. Convertissez vos graphiques dans la forme sans perte la plus légère. Envoyer les deux dans le même pipeline, c’est exactement comment on finit avec des logos flous et des fichiers plus lourds à la fois.

Méthode et données : le harnais de benchmark Patu sur la catégorie graphique (213 graphiques réels) ; les gains sont la réduction médiane par rapport au PNG d’origine, par outil. oxipng et le WebP sans perte sont octet pour octet ; pngquant est une réduction de palette avec pertes, quasi exacte sur du contenu en aplats.