WebP vs AVIF en 2026 : prise en charge, poids et code de repli

WebP vs AVIF en 2026 : servez AVIF en premier avec un repli WebP ou JPEG quand vous pouvez encoder à l’avance, et utilisez WebP seul quand vous avez besoin d’un encodage rapide ou d’un format unique et simple. Les deux sont Baseline largement disponibles à octobre 2026, donc la prise en charge par les navigateurs ne tranche plus. Les images WebP sont limitées à 16383 × 16383 px (FAQ WebP), ce qui ne compte que pour des panoramas très grands. AVIF a donné des fichiers plus petits à qualité visuelle égale dans les tests publiés par web.dev, et il gère le HDR ; WebP s’encode beaucoup plus vite (web.dev, mise à jour de 2023). L’écart en octets dépend de l’image, donc mesurez-le sur vos propres photos avant de vous décider.

WebP vs AVIF en un coup d’œil

Les deux formats se distinguent davantage par le coût et les fonctionnalités que par la prise en charge. Les données de prise en charge viennent de web-features 3.44.0 (22 octobre 2026) ; les autres lignes viennent des documents WebP de Google et de web.dev :

AVIF est passé à « nouvellement disponible » dans Baseline le 25 janvier 2024, quand Edge 121 l’a ajouté, et à « largement disponible » 30 mois plus tard, le 25 juillet 2026. Si vos statistiques montrent encore une part notable de navigateurs antérieurs à Safari 16 ou Edge 121, gardez un repli.

Poids des fichiers : lequel est le plus léger ?

AVIF est sorti plus léger dans les comparatifs publiés par web.dev, mais l’écart varie tellement qu’un pourcentage unique est trompeur. Le chiffre de Google pour WebP est de 25 à 34 % de moins que le JPEG. L’article de web.dev sur AVIF annonce « plus de 50 % d’économies par rapport au JPEG » tout en précisant que les économies exactes dépendent du contenu, des réglages d’encodage et de la cible de qualité, et la mise à jour de web.dev de 2023 citait Imgix qui constatait 60 % d’économies par rapport au JPEG et 35 % par rapport à WebP. Ces chiffres viennent de jeux d’images différents : mesurez donc les vôtres.

Comme les résultats dépendent du contenu, testez au moins trois types d’image de votre propre site : une grande photo, une capture ou un graphique avec du texte, et une petite vignette. Encodez chaque source à plusieurs niveaux de qualité et comparez le poids au niveau de qualité que vous acceptez, avec cwebp et avifenc de libavif :

# WebP, qualité 75
cwebp -q 75 hero.jpg -o hero.webp

# AVIF, qualité 60 comme valeur de départ à ajuster, avec 8 threads
avifenc -q 60 --jobs 8 hero.jpg hero.avif

ls -l hero.*

Squoosh fait la même chose dans le navigateur avec un curseur de comparaison côte à côte, plus rapide pour quelques images.

Vitesse d’encodage et outils

WebP s’encode plus vite, ce qui compte quand les images sont générées à la demande. La mise à jour de web.dev de 2023 indique qu’AVIF est l’encodeur le plus lent des formats courants pour un usage à la volée, tout en restant compétitif au réglage par défaut quand on encode à l’avance. avifenc a un réglage --speed de 0 (le plus lent) à 10 (le plus rapide), 6 par défaut ; des vitesses plus élevées coûtent en efficacité de compression. web.dev annonce un encodage environ 5 fois plus rapide avec 8 threads, sans décrire le test.

En pratique :

• Les chaînes de build (sites statiques, next/image avec cache, CDN d’images avec cache) gèrent bien AVIF, parce que chaque image n’est encodée qu’une fois.
• Le redimensionnement à la volée sans cache est le cas où la rapidité de WebP paie.
• Envois vers le CMS : vérifiez que votre CMS accepte AVIF avant de changer la chaîne. WordPress accepte les envois AVIF depuis la version 6.5 (2024), mais seulement si la bibliothèque Imagick ou GD du serveur la prend en charge ; Outils > Santé du site > Informations > Gestion des médias indique si c’est le cas (blog central de WordPress).

Servir les deux avec un repli picture

Utilisez l’élément <picture> pour que chaque navigateur choisisse le premier format qu’il supporte, de haut en bas, et se rabatte sur l’<img> :

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw">
  <img src="hero-800.jpg"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w" sizes="100vw"
       width="1600" height="900" alt="Product on a desk">
</picture>

Trois détails comptent sur téléphone :

• width et height sur l’<img> permettent au navigateur de réserver l’espace avant l’arrivée du fichier, ce qui évite un décalage de mise en page au chargement de l’image.
• srcset avec sizes permet à un téléphone de 390 px de large avec un ratio de pixels 2 de prendre le fichier 800w plutôt que le 1600w (390 × 2 = 780 pixels physiques). Un téléphone à ratio 3 a besoin de 1170 pixels physiques et prend le fichier 1600w. Le dimensionnement des images pour mobile est couvert dans rendre un site web compatible mobile.
• alt, loading et fetchpriority vont sur l’<img>, jamais sur <source>.

Pour les arrière-plans en CSS, image-set() avec type() fait le même travail et est Baseline largement disponible depuis mars 2026 :

.hero {
  background-image: image-set(
    url("hero.avif") type("image/avif"),
    url("hero.webp") type("image/webp"),
    url("hero.jpg") type("image/jpeg")
  );
}

Négociation de contenu sur un CDN

Certains CDN d’images choisissent le format à partir de l’en-tête Accept de la requête, au lieu de <picture> (consultez la documentation de votre CDN). Cela a un piège sur iPhone. Selon la liste des valeurs Accept par défaut de MDN (mise à jour en octobre 2026), Chrome et Edge 121+ envoient image/avif,image/webp,... et Firefox envoie aussi image/avif, alors que la valeur de Safari commence par image/webp et ne cite pas AVIF. Un CDN qui ne lit que Accept enverra donc du WebP à Safari, alors que Safari décode AVIF depuis la 16.4. Si vous voulez de l’AVIF sur iPhone, utilisez <picture> ou vérifiez comment votre CDN détecte Safari.

Et JPEG XL ?

JPEG XL n’est pas encore Baseline, donc il a besoin d’un repli. À octobre 2026, il est pris en charge par Safari 17+ (images fixes uniquement), Chrome 155, Firefox 158 (publié le 13 octobre 2026, selon ses notes de version) et Edge 155 (publié le 8 octobre 2026, selon ses notes de version). Samsung Internet ne le supporte pas, et MDN browser-compat-data 8.1.7 marque encore Edge comme non pris en charge, donc web-features ne le classe pas comme Baseline (MDN browser-compat-data). On peut l’ajouter comme troisième <source> au-dessus d’AVIF pour les navigateurs qui le supportent, au prix d’un encodage de plus par image.

Quand le JPEG reste valable

Un JPEG bien compressé est un choix raisonnable quand :

• vous ne pouvez pas modifier le balisage ni la chaîne de build, et le CMS ou le CDN ne convertit pas les formats à votre place ;
• l’image est une petite vignette dont les octets économisés ne représentent que quelques kilo-octets ;
• le fichier est destiné à être téléchargé, envoyé par e-mail ou modifié par les utilisateurs, et le JPEG fonctionne partout ;
• vous servez déjà la bonne taille selon l’appareil et la page passe son audit d’images.

Dans Lighthouse 13 (octobre 2025), l’ancien audit « Utiliser des formats d’image modernes » a été intégré à l’insight Livraison des images (Chrome for Developers). Considérez-le comme un indicateur des plus gros gains de la page ; vérifiez les dimensions des images avant le format. Le lancement et la lecture de l’audit sont expliqués dans le guide d’audit mobile avec Lighthouse.

Vérifiez le résultat sur une page à la taille d’un mobile

Après avoir changé de format, vérifiez deux choses : que les bons fichiers se chargent et que la mise en page n’a pas bougé. Le panneau Réseau de DevTools affiche le format et la taille réellement utilisés par chaque image ; filtrez sur Img et regardez la colonne Type. Pour la vitesse en données terrain, utilisez les méthodes du guide de test de vitesse mobile.

Pour la mise en page, ouvrez la page aux largeurs de téléphone. Mobile View Extension recharge l’onglet avec le user agent, la taille d’écran et le ratio de pixels d’un téléphone, donc vous voyez la mise en page mobile avec la version réelle de la page. Il ne montre que la mise en page : il ne mesure ni le poids des images ni le temps de chargement, et il s’affiche avec le moteur de Chrome sur ordinateur, donc le choix de format de Safari doit être vérifié dans Safari.

Questions fréquentes

AVIF est-il meilleur que WebP ?

Pour le poids des fichiers, oui dans les tests publiés : AVIF a donné des fichiers plus petits que JPEG et WebP à qualité visuelle proche dans les comparatifs de web.dev, et il gère le HDR. Vérifiez avec vos propres images, car l’écart dépend du contenu. WebP est préférable quand la vitesse d’encodage compte ou quand vos outils ne gèrent pas AVIF.

Tous les navigateurs prennent-ils AVIF en charge en 2026 ?

Tous les navigateurs majeurs actuels le font. AVIF est Baseline largement disponible depuis le 25 juillet 2026, avec une prise en charge à partir de Chrome 85, Firefox 113, Safari 16.4 (Safari iOS 16.1) et Edge 121.

Faut-il encore utiliser WebP ?

Oui, comme repli après AVIF, ou comme seul format moderne si votre chaîne encode les images à la demande. WebP est pris en charge par tous les navigateurs majeurs depuis Safari 14, en 2020.

AVIF nuit-il au référencement ?

Non. La Recherche Google cite AVIF parmi ses formats d’image pris en charge, à côté de WebP, JPEG, PNG, GIF, BMP et SVG (Google Search Central, mise à jour de mars 2026). La page ne décrit pas le format comme un signal de classement.