WebP et AVIF sont des formats d’image compressés, prévus pour remplacer un JPEG ou un PNG trop lourd dans la page. AVIF, à qualité visuelle proche, produit en général un fichier plus petit que WebP, qui lui-même est plus petit que le JPEG d’origine. Le gain ne compte que si le navigateur sait décoder le fichier, si la balise HTML propose un repli, et si vous n’avez pas oublié les dimensions. Sinon vous échangez des kilo-octets contre une image cassée ou un décalage de mise en page.
Proposer trois fichiers, pas un seul
Ne remplacez pas le JPEG par un AVIF unique dans le src. Écrivez un élément picture qui annonce les types dans l’ordre de préférence, et terminez par un img :
``html
<picture>
<source type="image/avif" srcset="photo.avif">
<source type="image/webp" srcset="photo.webp">
<img src="photo.jpg" alt="Atelier" width="800" height="450">
</picture>
``
Le navigateur prend la première source qu’il sait lire. Les autres ne sont pas téléchargées. L’img reste obligatoire : c’est lui qui porte le texte alternatif, la largeur, la hauteur, et le fichier de repli.
Gardez les mêmes pixels d’affichage d’une version à l’autre. Un AVIF recadré autrement que le JPEG décale la page selon le navigateur. Pour les écrans denses, ajoutez un srcset avec une variante plus large, plutôt que d’envoyer la photo de 4000 pixels à tout le monde. La largeur réelle dans la mise en page se déclare avec sizes, sinon le navigateur choisit souvent la plus grande variante.
Les réglages d’encodeur se choisissent à l’œil sur quelques photos représentatives, pas avec un pourcentage magique. Un palier courant est de partir d’une qualité AVIF autour de 50 et d’une qualité WebP autour de 75, puis de monter si les aplats ou les visages cassent. Ce sont des points de départ d’outil, pas des scores de page.
Dimensions, priorité, cache
Indiquez width et height sur l’img, ou réservez le ratio en CSS. Sans ça, le navigateur ne connaît la place de l’image qu’une fois le fichier lu, et le texte se déplace. Ce décalage est le CLS, l’un des signaux de terrain décrits dans l’article RUM et laboratoire.
L’image qui constitue le plus grand affichage au chargement (souvent le visuel d’en-tête) ne doit pas porter loading="lazy". Les images plus bas dans la page, si. Le lazy-loading sur l’image principale retarde justement l’élément que le navigateur devrait afficher en premier. Un fetchpriority="high" sur cette image-là est cohérent. Le poser sur toutes les images annule le tri.
Côté serveur, envoyez le bon Content-Type (image/avif, image/webp) et un cache long sur l’URL du fichier, avec un nom qui change quand le fichier change. Si vous négociez le format avec l’en-tête Accept au lieu d’un picture, le cache doit varier sur Accept. Sinon un premier visiteur en WebP fait mettre en cache un fichier qu’un visiteur suivant reçoit à tort. L’élément picture évite cette classe de bugs : chaque URL est un seul format.
Ce qu’on ne convertit pas
- Les SVG d’interface, déjà adaptés.
- Les images qui doivent rester au pixel près (capture annotée, schéma technique) : testez, ou gardez un PNG.
- Une animation : un GIF converti en une seule image fixe n’est pas une optimisation, c’est une régression. AVIF et WebP animés existent, mais il faut vérifier le lecteur.
- La même photo répétée en vingt variantes d’URL sans cache : le format ne corrige pas une génération à la volée trop lente. Le temps jusqu’au premier octet de l’image se mesure à part. Si ce délai est le sujet, l’article sur les causes d’une page lente commence par là, avant le choix du codec.
SiteGarde ne choisit pas le format de vos images. Il peut seulement signaler qu’une URL d’image commence à répondre autre chose qu’un succès. Le poids et le format se jugent dans le navigateur et dans un essai de laboratoire, pas dans un code HTTP 200.