AVIF ou WebP : lequel est le plus léger, et quand

Ce que sont AVIF et WebP

WebP est le format d'image de Google, annoncé en 2010. Son mode avec perte compresse une image comme le codec vidéo VP8 compresse une seule trame ; un mode sans perte distinct, VP8L, est conçu pour les graphismes aux contours nets et aux couleurs peu nombreuses. Les deux modes gèrent la transparence, et le WebP animé peut remplacer le GIF.

AVIF (AV1 Image File Format) stocke une trame compressée avec AV1, le codec vidéo libre de redevances de l'Alliance for Open Media, dans un conteneur HEIF. Sa spécification 1.0 date de 2019. Les outils de codage d'AV1 ont une décennie d'avance sur ceux de VP8 : AVIF conserve donc plus de détail par octet sur les photographies, et ajoute la couleur 10 et 12 bits ainsi que le HDR. Le prix, c'est le temps d'encodage : produire un AVIF demande nettement plus de CPU qu'un WebP de la même image, c'est pourquoi les services d'images convertissent une fois et mettent le résultat en cache.

La compatibilité n'est plus la question décisive. Selon caniuse.com (données du 30 septembre 2026), environ 97 % des navigateurs en circulation affichent WebP et environ 95 % AVIF. WebP fonctionne depuis Chrome 32, Firefox 65 et Safari 14 (sous macOS 11 ou plus récent) ; AVIF depuis Chrome 85, Firefox 93, Safari sur iOS 16, Safari 16.4 sur Mac (images fixes dès Safari 16.1, sous macOS 13 Ventura ou plus récent) et Edge 121. Les quelques pour cent restants expliquent pourquoi un repli compte encore, et avec la négociation côté serveur, ce repli ne coûte rien.

Lequel est le plus léger ? Tout dépend de l'image

La plupart des comparatifs citent un seul chiffre, « WebP est 30 % plus léger » ou « AVIF divise vos images par deux », calculé en moyenne sur des photographies. Un vrai site sert aussi des captures d'écran, des logos et des icônes, et là, le classement peut s'inverser. Le 5 octobre 2026, nous avons fait passer quatre images par l'optimiseur d'images de CDN.com.tr, avec ses réglages de production, et compté les octets produits par chaque format.

Photo d'actualité, JPEG, 1920×1080. Original 262 025 octets ; JPEG optimisé 186 137 ; WebP 113 860 ; AVIF 86 936. Le cas d'école : WebP pèse 39 % de moins que le JPEG optimisé, et AVIF encore 24 % de moins que WebP, soit un tiers des octets de l'original.

Photo d'actualité, JPEG, 926×594. Original 131 472 octets ; JPEG optimisé 93 348 ; WebP 89 360 ; AVIF 77 452. Le même genre d'image, plus petite et déjà bien compressée : face au JPEG, WebP ne gagne que 4 %, AVIF 17 %.

Capture du panneau de contrôle, PNG, 1156×775. Original 105 078 octets ; PNG optimisé (pngquant et optipng) 40 379 ; WebP 41 218 ; AVIF 27 942. Les aplats et le texte sont le point fort d'un PNG à palette : WebP est sorti 839 octets plus lourd que le PNG, alors qu'AVIF restait 31 % plus léger que lui.

Favicon, PNG, 16×16. Original 701 octets ; PNG optimisé 483 ; WebP 314 ; AVIF 682. À cette taille, c'est le conteneur qui décide : 429 des 682 octets de l'AVIF sont des boîtes HEIF qui décrivent l'image avant le moindre pixel, alors que l'enveloppe du WebP fait 46 octets. AVIF a fini 41 % plus lourd que le PNG, et WebP était le plus léger.

C'est la tendance qui se transpose. AVIF gagne nettement sur les photographies et les captures détaillées ; WebP est un second choix sûr ; sur les aplats, un PNG bien optimisé peut battre WebP, et sur les petites icônes, le surcoût fixe d'AVIF l'emporte sur sa meilleure compression. Les octets exacts dépendent de l'encodeur et de ses réglages : lisez-les comme la mesure d'un service, pas comme une loi. Aucun pourcentage ne vaut pour toutes les images : le test fiable consiste à encoder l'image et à comparer les octets.

Comment un serveur choisit le format

Chaque requête d'image porte un en-tête Accept qui liste les formats que le navigateur sait afficher. Chrome envoie image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 ; un navigateur sans AVIF omet image/avif. Un serveur ou un CDN qui convertit les images lit cette liste et répond à la même URL avec de l'AVIF, du WebP ou l'original. Le nom du fichier ne change pas, si bien que hero.png peut arriver en AVIF : c'est l'en-tête Content-Type, et non l'extension, qui dit ce qui a été envoyé.

Comme une URL a désormais plusieurs réponses possibles, la réponse doit porter Vary: Accept. Cet en-tête demande à chaque cache du trajet, du CDN au navigateur en passant par le proxy d'une entreprise, de garder une copie distincte par valeur d'Accept. Sans lui, un cache partagé peut remettre l'AVIF reçu par un visiteur au suivant, dont le navigateur ne sait pas l'afficher.

L'autre approche déplace le choix dans le HTML. Un élément <picture> liste des fichiers <source> avec type="image/avif" et type="image/webp", le navigateur prend le premier type qu'il prend en charge, et l'<img> à l'intérieur sert de repli. Pas de logique côté serveur ni de Vary, mais il faut produire et stocker vous-même chaque variante et tenir le balisage à jour. Dans les deux cas, vérifier ce qu'un navigateur reçoit vraiment demande trois requêtes.

Une image, trois en-têtes Accept : comparez ce qui revient

# un navigateur qui accepte AVIF et WebP
curl -so /dev/null -w '%{content_type} %{size_download} octets\n' \
  -H 'Accept: image/avif,image/webp,*/*' https://example.com/hero.png

# un navigateur qui ne connaît que WebP
curl -so /dev/null -w '%{content_type} %{size_download} octets\n' \
  -H 'Accept: image/webp,*/*' https://example.com/hero.png

# un client qui ne demande rien de particulier
curl -so /dev/null -w '%{content_type} %{size_download} octets\n' \
  -H 'Accept: */*' https://example.com/hero.png

# l'en-tête qui garde les caches partagés honnêtes (un GET, pas un HEAD)
curl -s -D - -o /dev/null -H 'Accept: image/avif,*/*' \
  https://example.com/hero.png | grep -i '^vary'

Vérifiez ce que sert votre site

Le vérificateur ci-dessous lance ces requêtes pour une page entière. Il lit le HTML de la page, prend jusqu'à 20 images dans <img>, srcset, <picture> et og:image, et demande chacune deux fois : une fois comme un navigateur actuel (Accept: image/avif,image/webp,…), une fois comme un client qui accepte tout (Accept: */*). Il lit les premiers octets de chaque réponse pour connaître le vrai format, quoi qu'en dise le nom du fichier, compte les octets, et indique Vary et l'état du cache. Une simple adresse d'image fonctionne aussi.

Les requêtes partent de notre serveur en Turquie : un CDN peut donc nous répondre depuis un autre emplacement que pour vos visiteurs. Les images ajoutées par JavaScript après le chargement et les arrière-plans CSS ne figurent pas dans le HTML et ne sont pas vérifiés. La page du vérificateur détaille toutes les limites.

Lire les résultats

AVIF ou WebP. Un navigateur qui demandait des formats modernes en a reçu un. La taille indiquée à côté est ce que ce navigateur a téléchargé ; la colonne « Autres navigateurs » est ce que reçoit tout navigateur sans AVIF ni WebP. La ligne d'économie n'additionne que les images dont les deux réponses ont été lues en entier et sont arrivées dans des formats différents : c'est une mesure, jamais une estimation.

Original uniquement. Même un navigateur qui demandait AVIF et WebP a reçu du JPEG, du PNG ou du GIF : rien ne convertit l'image en chemin. Si certaines images arrivent en AVIF et d'autres seulement dans leur format d'origine, cherchez ce que le second groupe a en commun : un autre hôte, un chemin qu'aucune règle ne couvre, une extension que le convertisseur ignore.

Le même fichier pour tous les navigateurs. Les deux requêtes ont reçu le même format. C'est le résultat d'un site sans négociation, et aussi d'un site qui sert déjà des fichiers .webp à tout le monde : tous les navigateurs actuels les affichent, mais l'économie supplémentaire d'AVIF reste inutilisée. Sans rien à comparer, aucune économie n'est affichée.

Sans Vary: Accept. La réponse change selon Accept mais ne le dit pas, et les caches partagés peuvent la conserver. Corrigez celui-ci en premier : c'est le seul résultat de la liste qui peut montrer une image cassée à un visiteur.

Limité ou bloqué. Certains sites répondent aux requêtes automatisées par un 429, un 403, une vérification anti-bot ou une petite page 503. Le vérificateur cesse alors d'interroger cet hôte pour le reste de la vérification et marque les images restantes comme non vérifiées. Cela renseigne sur la protection du site, pas sur ses images : réessayez quelques minutes plus tard, ou vérifiez directement l'adresse d'une image.

Une stratégie raisonnable : AVIF, puis WebP, jamais plus lourd

Au bout du compte, la stratégie que veulent la plupart des sites est courte. Proposez AVIF d'abord : sur les photographies et les captures détaillées, il est le plus léger, et de loin. Gardez WebP en second choix pour les navigateurs sans AVIF. Gardez l'original comme dernier repli, pour que chaque navigateur reçoive une image qu'il sait afficher.

Ajoutez ensuite la règle que notre favicon nous a apprise : comparez les octets image par image, et n'envoyez jamais un fichier converti plus lourd que celui que vous auriez envoyé sinon. Le format est un moyen ; le but, c'est moins d'octets. Une chaîne qui convertit à l'aveugle alourdit une partie de vos images et les déclare quand même optimisées.

Deux remarques pratiques. Convertissez une fois et mettez le résultat en cache, en périphérie d'un CDN ou lors du build, plutôt qu'à chaque requête : c'est l'encodage AVIF qui coûte cher. Et gardez en SVG, quand c'est possible, les logos et icônes dessinés plutôt que photographiés : il n'y a rien à convertir, et ils restent nets sur tous les écrans.

AVIF et WebP sur CDN.com.tr

L'optimisation des images est un interrupteur du panneau de contrôle, pour tout le compte ou pour une seule règle de diffusion. Quand elle est activée, la périphérie sert les images JPEG et PNG en WebP aux navigateurs qui le prennent en charge ; notre service d'images convertit chaque image une fois et la périphérie met le résultat en cache. Pour le compte, vous pouvez aussi choisir WebP + AVIF : les navigateurs qui acceptent AVIF reçoivent alors de l'AVIF, les autres navigateurs modernes du WebP et tous les autres l'image dans son format d'origine, le tout depuis la même URL, avec Vary: Accept et une copie en cache distincte par format.

Le traitement est décompté de votre quota mensuel, l'AVIF à un taux plus élevé que le WebP parce qu'il demande plus de CPU ; le panneau affiche le taux à côté de l'interrupteur. Lancez le vérificateur ci-dessus sur vos propres pages pour voir, image par image, quel format reçoit chaque navigateur et combien d'octets il pèse.