Bhinish Dhiman
PNG en WebP : combien on gagne vraiment, mesuré sur onze images
Traduit de l’original en anglais. Lire l’original
Convertir du PNG en WebP à la qualité 0.82 dans Chromium 153 a réduit quatre photos de 1600 × 900 de 92.5 % à 96.5 %, un logo en aplats de 800 px de 68.7 % et un détourage photographique transparent de 94.2 %. Les icônes ont pris le chemin inverse : 64 px a grossi de 32.7 %, 32 px de 68.5 % et 16 px de 116 %. Sur les visuels en aplats, le WebP fait jeu égal avec un PNG en palette.
Le chiffre que tout le monde cite pour le WebP face au PNG vient de l’étude de Google sur le WebP sans perte. Notre convertisseur n’écrit pas de WebP sans perte (aucun navigateur ne le fait par défaut depuis un canvas) : ce chiffre ne décrit donc pas ce qu’il produit. Voici ce qu’il produit.
La mesure
Nous avons préparé onze PNG : quatre photos de 1600 × 900, une photo avec un masque de transparence radial adouci, un logo en aplats de 800 × 800 sur fond et le même logo sur transparence, et une icône de coche de 32 unités rastérisée à 16, 32, 64 et 128 px. Chacun a été converti dans Chromium 153.0.8010 sans interface, par les mêmes appels que convertOne() dans src/lib/convert/image.ts : createImageBitmap, dessin sur un canvas, canvas.toBlob('image/webp', 0.82), 0.82 étant la valeur par défaut du convertisseur. Nous avons aussi réenregistré chaque PNG avec libpng à l’effort maximal, ainsi qu’en PNG en palette, pour disposer d’une référence équitable pour les visuels en aplats. Exécuté le 1er octobre 2026.
| Image | PNG tel que fourni | PNG optimisé | WebP 0.82 | Écart par rapport au fichier fourni |
|---|---|---|---|---|
| Photo A, 1600 × 900 | 1 568 028 o | 698 559 o | 55 498 o | −96.5 % |
| Photo B | 2 327 903 o | 903 228 o | 142 062 o | −93.9 % |
| Photo C | 3 140 320 o | 834 110 o | 148 002 o | −95.3 % |
| Photo D | 2 959 239 o | 932 712 o | 221 848 o | −92.5 % |
| Photo, masque alpha adouci | 3 314 685 o | 521 151 o | 192 402 o | −94.2 % |
| Logo en aplats, opaque | 35 475 o | 11 849 o (palette) | 11 108 o | −68.7 % |
| Logo en aplats, transparent | 27 876 o | 11 352 o (palette) | 13 992 o | −49.8 % |
| Icône 128 px | 2 097 o | 1 635 o (palette) | 2 042 o | −2.6 % |
| Icône 64 px | 1 020 o | 917 o (palette) | 1 354 o | +32.7 % |
| Icône 32 px | 559 o | 518 o (palette) | 942 o | +68.5 % |
| Icône 16 px | 332 o | 330 o (palette) | 718 o | +116.3 % |
Les photos
Une photo stockée en PNG est le cas pour lequel le format n’a jamais été conçu, et le gain est énorme parce que le point de départ est absurde : un fichier de 1.5 Mo à 3.1 Mo qu’un encodeur avec perte peut représenter en 55 Ko à 222 Ko. Même face à un PNG correctement optimisé, le gain va de 76 % à 92 %. Face au JPEG avec le même réglage 0.82, le WebP était plus léger sur les quatre photos (55 Ko contre 105 Ko pour la photo A), mais un indice de qualité est un réglage propre à chaque encodeur : il s’agit d’une comparaison entre deux résultats, pas entre deux réglages.
Les visuels en aplats, avec une référence honnête
Les 68.7 % sur le logo sont réels mais flattent le WebP, car le PNG fourni était un export non optimisé. Face à un PNG en palette (ce qu’écrit un optimiseur PNG pour un graphique à quatre couleurs, et ce que produit sans perte notre compresseur d’images), le WebP est 6 % plus léger sur le logo opaque et 23 % plus lourd sur le logo transparent. Sur les graphiques en aplats, les deux formats font jeu égal, et le PNG garde les bords nets à l’identique.
Les icônes
En dessous d’environ 128 px, le WebP perd, et la perte s’accentue à mesure que l’image rétrécit : le format porte un coût fixe de conteneur et d’en-têtes qu’un PNG de 332 octets n’a pas la place d’amortir. À 16 px, le WebP pèse plus du double du PNG. Un jeu de favicons doit rester en PNG, et notre générateur de favicon écrit du PNG pour cette raison.
La transparence perd des pixels, quel que soit le format
Nous avons aussi demandé à Chromium un WebP de qualité 1.0, qu’il écrit sans perte : les quatre photos opaques et le logo opaque se sont décodés à l’identique, bit pour bit, par rapport à la source. Aucune des images à transparence partielle n’y est parvenue. Dans la photo au masque adouci, 39.77 % des pixels différaient après l’aller-retour ; dans l’icône de 16 px, 8.59 %. Ce n’est pas la faute de l’encodeur WebP. Un canvas stocke l’alpha prémultiplié : un pixel à demi transparent est arrondi à l’entrée et ne peut pas être restitué à la sortie. Tout convertisseur qui passe par un canvas, le nôtre compris, inflige cela aux bords adoucis, quel que soit le réglage de qualité et quel que soit le format de sortie. Pour un graphique dont la transparence doit survivre à l’identique, ne le réencodez pas du tout via un canvas.
Que faire de ce tableau
Photos : convertissez-les, et attendez-vous à plus de 90 %. Graphiques en aplats : optimisez d’abord le PNG et ne convertissez que si le résultat reste trop lourd. Icônes sous 128 px : laissez-les telles quelles. Tout ce qui a une transparence adoucie devant rester exacte : laissez-le aussi.