Deux formats modernes, deux histoires différentes
WebP, c'est Google qui l'a lancé au début des années 2010, avec une idée fixe : remplacer à la fois le JPEG et le PNG par un seul format plus léger. Il gère la compression avec perte, sans perte, la transparence et même l'animation. Longtemps, son seul vrai frein a été Safari, qui a tardé à le lire.
AVIF est plus jeune. Il dérive du codec vidéo AV1, porté par l'Alliance for Open Media, un consortium qui réunit une bonne partie des grands noms du web (Google, Mozilla, Apple, Netflix, entre autres). En gros, on prend une image fixe et on la compresse avec des outils pensés pour la vidéo moderne. Ça explique à la fois sa force, la compression, et son défaut, le temps de calcul.
Pour un intégrateur, la question n'est donc pas de savoir lequel est moderne. Les deux le sont. C'est plutôt : combien je gagne en poids, combien ça me coûte en complexité, et est-ce que tout le monde, navigateurs comme Googlebot, sait lire le résultat ?
Poids à qualité égale : AVIF devant, mais pas partout
Sur des photos, AVIF produit en général les fichiers les plus légers à qualité visuelle comparable. WebP reste de son côté nettement plus léger qu'un JPEG. Google annonce, dans la documentation officielle du format WebP, des fichiers avec perte d'environ un quart à un tiers plus petits qu'un JPEG équivalent.

Là où je nuance, c'est sur le type d'image. AVIF brille sur les photos, les dégradés et les ciels, là où le JPEG fait apparaître des bandes et des blocs. En compression forte, il a en revanche tendance à lisser les textures fines : le grain d'un tissu, une chevelure, du feuillage. L'image reste propre, mais un œil attentif la trouve un peu « plastique ». WebP en perte a son propre travers : il réduit toujours la précision des couleurs, ce qui peut faire baver les contours sur du texte coloré ou des captures d'interface.
Mon conseil ? Méfiez-vous des comparatifs génériques, vos images comptent plus que les leurs. Prenez trois visuels représentatifs de votre site (une photo produit, une image d'ambiance, une capture d'écran), passez-les dans Squoosh, l'outil en ligne gratuit de l'équipe Chrome, et comparez côte à côte avec le curseur. Dix minutes, et vous savez quel réglage tenir.
Navigateurs et Googlebot : plus de vrai perdant
Bonne nouvelle, la compatibilité est presque une question réglée. WebP est lu par tous les navigateurs actuels depuis plusieurs années. AVIF a mis plus de temps : Chrome et Firefox l'ont adopté en premier, Safari a suivi, et Edge a été le dernier des grands à l'activer, début 2024.
Côté moteur, même constat. La page de Google consacrée au référencement des images liste les formats pris en charge par la recherche, et AVIF y figure aux côtés de WebP, JPEG, PNG, GIF, BMP et SVG. Googlebot lit donc vos AVIF, et Google Images peut les indexer comme n'importe quelle autre image.
Le risque se situe ailleurs, dans le reste de la chaîne : certains réseaux sociaux, outils d'aperçu de liens ou clients mail peuvent encore mal gérer ces formats. Pour l'image Open Graph, celle qui s'affiche quand on partage la page, je reste par prudence sur un JPEG ou un PNG.
Le prix à payer avec AVIF
AVIF se paie au moment de l'encodage. Générer un AVIF demande beaucoup plus de calcul qu'un WebP. Sur une poignée d'images, aucune importance. Sur un catalogue de plusieurs milliers de photos produits, ou avec un redimensionnement à la volée sur un petit serveur, ça devient un vrai sujet : files d'attente, processeur saturé, temps de build qui s'allonge.
Selon votre stack, le support n'est pas toujours là non plus. Les versions récentes de WordPress acceptent l'AVIF, mais seulement si la bibliothèque d'images installée sur le serveur (Imagick ou GD) sait le traiter. Je vérifie toujours ce point avant de promettre quoi que ce soit.
Le comparatif en un coup d'œil
| Critère | WebP | AVIF |
|---|---|---|
| Poids à qualité égale | Bien plus léger qu'un JPEG | Le plus léger, surtout en photo |
| Vitesse d'encodage | Rapide | Lente, gourmande en processeur |
| Navigateurs actuels | Tous | Tous les grands (Edge depuis 2024) |
| Recherche Google et Google Images | Pris en charge | Pris en charge |
| Transparence et animation | Oui | Oui |
| Point faible | Couleurs moins précises en perte | Textures lissées en forte compression |
| Idéal pour | Usage général, gros volumes | Grandes photos, image principale de la page |
Aucun des deux ne gagne sur toute la ligne. C'est justement pour ça qu'on n'est pas obligé de choisir.
Ma méthode : servir les deux avec la balise picture
Plutôt que de trancher, laissez le navigateur décider. La balise picture sert exactement à ça : vous proposez plusieurs sources, il prend la première qu'il sait lire.
<picture>
<source srcset="/img/cuisine.avif" type="image/avif">
<source srcset="/img/cuisine.webp" type="image/webp">
<img src="/img/cuisine.jpg" alt="Cuisine ouverte avec îlot central en chêne"
width="1600" height="900">
</picture>L'ordre compte : AVIF d'abord, WebP ensuite, JPEG en dernier recours dans la balise img. C'est elle que Google utilise pour repérer l'image, et c'est elle qui porte le texte alternatif, les dimensions et, si besoin, l'attribut loading. Au passage, si vous comptez mettre en place le chargement différé de vos images sans bloquer leur indexation, laissez le visuel du haut de page en chargement normal.
Autre option si vous passez par un CDN d'images : la négociation de contenu. Le serveur lit l'en-tête Accept envoyé par le navigateur et renvoie le meilleur format possible sur une seule et même URL. C'est confortable, à une condition : renvoyer un en-tête Vary: Accept. Sans lui, un cache intermédiaire peut très bien servir un AVIF à un navigateur incapable de l'afficher.
Quel format pour quelle image
- Photo d'en-tête et grands visuels : AVIF, avec WebP en secours.
- Photos produits en grande quantité : WebP, plus simple à générer à la chaîne (AVIF si votre CDN s'occupe de la conversion).
- Captures d'écran, interfaces avec du texte : WebP sans perte ou AVIF en qualité élevée, à tester sur vos fichiers.
- Logos, icônes, pictos : ni l'un ni l'autre, du SVG.
- Image de partage Open Graph : JPEG ou PNG.
Et le SEO dans tout ça ?
Soyons clairs : Google ne donne aucun bonus à un fichier parce qu'il se termine par .avif. Le format n'est pas un critère de classement en soi. Ce qui compte, c'est son effet sur la vitesse, et en particulier sur le LCP, l'indicateur des Core Web Vitals qui mesure l'affichage du plus gros élément visible à l'écran. Sur beaucoup de pages, ce plus gros élément, c'est justement une image.
Alléger celle-là, c'est le levier le plus direct. Le reste dépend de l'infrastructure : une image deux fois plus légère servie par une machine poussive reste lente, et c'est une des raisons pour lesquelles on finit par s'interroger sur l'impact d'un hébergement mutualisé ou d'un VPS sur le référencement dès qu'un site grossit.
Pour savoir où vous en êtes, PageSpeed Insights signale les images trop lourdes ou servies dans un format ancien. C'est souvent l'une des premières lignes que je regarde quand je dois faire un audit SEO technique avec les moyens du bord.
Le format d'image ne fait pas ranker une page, mais une image trop lourde suffit parfois à plomber son LCP.
