AVIF vs WebP vs JPEG : des chiffres réels à qualité égale

La plupart des affirmations du type « AVIF est 50 % plus léger que JPEG » comparent un JPEG en qualité 75 à un AVIF réglé autrement. Ce n’est pas une comparaison : un -q 75 chez un encodeur ne donne pas la même image qu’un -q 75 chez un autre. La seule question honnête est : à qualité perceptuelle fixe, combien d’octets chaque format demande-t-il ?

Nous l’avons mesuré. Pas sur une poignée d’images vitrines, mais sur 1,900+ photographies réelles, avec les encodeurs réels, notées par une métrique perceptuelle plutôt que par un chiffre de qualité deviné.

Comment nous l’avons mesuré

• Images : le jeu de photos de notre benchmark public, 1,998 photographies réelles, en majorité des originaux Wikimedia Commons, couvrant portraits, paysages, textures, faible lumière et détails fins. Pas un cas favorable trié sur le volet.
• Encodeurs, chacun l’outil de référence : JPEG via libjpeg-turbo, WebP via cwebp (libwebp), AVIF via avifenc (libaom), et JPEG XL via cjxl (libjxl) en bonus.
• La métrique : ssimulacra2, un score de qualité perceptuelle où un chiffre plus élevé signifie plus proche de l’original. Il corrèle avec ce que l’œil perçoit bien mieux que le PSNR ou un simple chiffre de qualité. Au-dessus de 90, l’image est indiscernable de la source ; autour de 85, la qualité est élevée ; autour de 80, elle est bonne.
• La méthode : pour chaque image, nous encodons chaque format sur toute une grille de qualité, nous notons chaque sortie avec ssimulacra2, puis nous interpolons le nombre d’octets nécessaires à ce format pour atteindre un score cible. C’est la comparaison juste : chaque format est tenu à la même qualité perçue, et on lit le prix en octets. Nous indiquons la médiane sur les images où tous les formats atteignent effectivement la cible.

Ce dernier point compte : comparer cwebp -q 80 à avifenc -q 80 n’a pas de sens. Comparer « le WebP qui a l’air aussi bon que l’AVIF », c’est tout l’enjeu.

Les chiffres

À ssimulacra2 85 (qualité élevée, difficile à distinguer de l’original), sur les 548 photos où les quatre formats l’atteignent :

À qualité égale, AVIF est 16 % plus léger que WebP, et les deux devancent nettement JPEG.

À ssimulacra2 80 (bonne qualité, une cible web courante), sur 1,884 photos :

L’avance d’AVIF se creuse à 80 (−29% vs JPEG, −21% vs WebP) : il conserve le détail à des débits plus faibles, là où JPEG et WebP commencent à craquer.

Ces chiffres concordent avec la littérature indépendante : un AVIF environ 25–30% sous JPEG à qualité équivalente est un résultat largement reproduit. Ce que cette mesure apporte, c’est qu’elle est perceptuelle, à qualité égale, sur un grand jeu de photos non trié pour l’occasion.

Les réserves, sans détour

• La référence JPEG est libjpeg-turbo, le JPEG que presque tout le monde utilise aujourd’hui. Les encodeurs JPEG modernes (mozjpeg, jpegli) comblent une partie de l’écart tout en restant pleinement compatibles JPEG : si vous ne pouvez servir que du JPEG, passez à l’un d’eux avant toute autre chose.
• WebP est plafonné en qualité, en pratique. Son encodeur avec pertes atteint un plafond : sur les photos très détaillées, il peine à atteindre ne serait-ce que ssimulacra2 90. C’est une vraie limite, pas un choix de réglage.
• JPEG XL est le plus léger ici, mais vous ne pouvez pas le servir aux navigateurs. Aucun navigateur majeur ne l’active par défaut en 2026. Il figure ici comme plafond technique, pas comme recommandation de déploiement.
• AVIF coûte du temps d’encodage. avifenc est bien plus lent que cwebp ou cjpeg. Ça ne pose pas de problème pour des assets stockés derrière un CDN, moins pour un encodage à la volée requête par requête : c’est exactement pour ça qu’un service à qualité ciblée met en cache.

Ce que ça change en pratique

Servez de l’AVIF avec un repli WebP puis JPEG, et visez un score perceptuel, pas un chiffre de qualité. Un -q fixe produit une qualité incohérente d’une image à l’autre : certaines sur-compressées et visiblement dégradées, d’autres inutilement lourdes. Chercher la qualité d’encodage de chaque image pour atteindre un score ssimulacra2 cible, c’est ce qui donne à la fois les octets les plus faibles et une qualité que vous pouvez réellement garantir.

C’est ce que fait Patu : il cherche la qualité d’encodage propre à chaque image pour atteindre une cible perceptuelle, et renvoie de l’AVIF et du WebP avec un repli JPEG, derrière un CDN. Les chiffres ci-dessus expliquent pourquoi le défaut est AVIF en premier.

curl -X POST "https://patu.dev/v1/compress?formats=avif,webp,fallback&target=85" \
  -H "X-Api-Key: $PATU_KEY" \
  --data-binary @photo.jpg -o photo.avif

Vous lui donnez une qualité cible ; il vous rend le fichier le plus léger à cette qualité, dans les formats qu’un navigateur sait effectivement utiliser.

Méthode et données : le harnais de benchmark Patu sur la catégorie photo ; ssimulacra2 via l’implémentation rust-av ; encodeurs libjpeg-turbo, libwebp, libaom, libjxl dans leurs versions publiées. Les tailles sont la médiane sur les photos où chaque format atteint le score cible.