Images web en 2026 : AVIF, WebP et lazy-load bien réglés

Un site qui charge encore des JPEG en pleine résolution en 2026, c’est un LCP au-dessus de 4 secondes sur mobile et un score PageSpeed qui plafonne à 60. Le problème n’est plus de savoir s’il faut compresser les images : tout le monde le sait depuis dix ans. Le problème, c’est que la plupart des sites appliquent la mauvaise stratégie — un plugin de compression générique, un lazy-load posé sur toutes les images sans distinction, et des balises <img> sans width/height qui font sauter la mise en page au chargement. Voici comment régler ça correctement, format par format et attribut par attribut.

AVIF, WebP, JPEG : lequel utiliser et quand

AVIF est aujourd’hui le format le plus efficace pour les photos : à qualité visuelle équivalente, il pèse environ 40 à 50 % de moins qu’un JPEG optimisé, et souvent 20 à 30 % de moins qu’un WebP. C’est le format à privilégier pour les visuels lourds — bannières, photos produit haute résolution, images d’illustration en pleine largeur.

WebP reste pertinent dans deux cas précis : les images avec transparence (remplace le PNG avec un gain de poids massif) et les contextes où l’encodage AVIF est trop coûteux à générer en masse — un catalogue e-commerce de plusieurs dizaines de milliers de références, par exemple, où le temps de build ou le coût de calcul à la volée devient un vrai sujet d’infrastructure.

Le JPEG et le PNG ne doivent plus jamais être servis directement au navigateur. Ils restent utiles comme source de référence côté back-office, mais le visiteur doit toujours recevoir AVIF ou WebP en sortie, avec un fallback automatique.

Le pattern HTML qui fait le travail correctement

La bonne pratique n’est pas de remplacer l’extension du fichier, c’est de laisser le navigateur choisir le meilleur format qu’il sait décoder, via <picture> :

<picture>
  <source srcset="produit-800.avif 800w, produit-1600.avif 1600w" type="image/avif">
  <source srcset="produit-800.webp 800w, produit-1600.webp 1600w" type="image/webp">
  <img src="produit-800.jpg" srcset="produit-800.jpg 800w, produit-1600.jpg 1600w"
       sizes="(max-width: 768px) 100vw, 800px"
       width="800" height="600" alt="Description précise du produit"
       loading="lazy" decoding="async">
</picture>

Trois éléments sont non négociables dans ce bloc : les attributs width et height (ils réservent l’espace et évitent le décalage de mise en page, donc le CLS), l’attribut sizes qui indique au navigateur la largeur réelle affichée pour qu’il ne télécharge pas une image deux fois trop grande sur mobile, et le fallback JPEG dans la balise img pour les rares navigateurs qui ne gèrent ni AVIF ni WebP.

Lazy-load : la règle qui casse le plus de sites

L’erreur la plus fréquente en 2026 reste d’appliquer loading="lazy" à toutes les images sans exception, y compris à l’image affichée dès le chargement de la page — souvent celle qui détermine le LCP (Largest Contentful Paint). Résultat : le navigateur retarde volontairement le téléchargement de l’image la plus importante de la page, et le LCP explose.

La règle est simple : l’image visible au premier écran (hero, photo produit principale, image d’en-tête d’article) doit être en loading="eager" — ou sans attribut de lazy-load du tout — et idéalement marquée fetchpriority="high" pour indiquer au navigateur de la prioriser dans la file de téléchargement. Toutes les images situées sous la ligne de flottaison, elles, passent en loading="lazy" sans exception.

<!-- image du hero, au-dessus de la ligne de flottaison -->
<img src="hero.avif" fetchpriority="high" loading="eager" width="1920" height="800" alt="...">

<!-- image plus bas dans la page -->
<img src="visuel-2.avif" loading="lazy" decoding="async" width="800" height="500" alt="...">

Un audit rapide consiste à ouvrir l’onglet Réseau des outils de développement, filtrer sur les images, et vérifier que la première image chargée correspond bien à celle qui apparaît en premier à l’écran. Si ce n’est pas le cas, le lazy-load est mal réglé.

Où générer les formats : build time vs à la volée

Deux approches coexistent, et le choix dépend du volume d’images et de la fréquence de mise à jour du contenu. Pour un site vitrine ou un blog avec quelques dizaines d’images ajoutées par mois, la génération à la construction (via sharp en Node.js ou libvips côté PHP) suffit largement : chaque image uploadée est convertie une fois en AVIF et WebP à plusieurs résolutions, puis servie telle quelle.

Pour un catalogue e-commerce ou un site à fort trafic avec des milliers de références, la génération à la volée via un CDN qui négocie le format selon l’en-tête Accept du navigateur (Cloudflare Images, Bunny CDN, ou un service équivalent) évite de stocker des dizaines de variantes par image et absorbe automatiquement l’ajout de nouveaux formats à l’avenir, sans reprocesser tout l’historique.

Ce que je déconseille systématiquement, c’est le plugin de compression générique installé sur un WordPress construit avec un page builder : il tourne en tâche de fond, dégrade parfois la qualité de façon incontrôlée, et n’a aucune visibilité sur la stratégie de sizes ni sur ce qui est réellement above the fold. Sur les projets où je construis un thème WordPress sur mesure en PHP natif, la génération des formats et le lazy-load sont intégrés directement dans le thème, avec un contrôle précis de quelle image reçoit quel traitement — pas de couche plugin supplémentaire à maintenir.

Le piège spécifique à WordPress et WooCommerce

WordPress génère par défaut une dizaine de tailles de vignettes par image uploadée, dans le format d’origine (souvent du JPEG non compressé venant directement d’un appareil photo ou d’un export Photoshop). Sans intervention, une fiche produit WooCommerce peut charger six à huit images entre 200 Ko et 1,5 Mo chacune. Ajoutez à ça un thème construit sur Elementor ou Divi, qui empile ses propres wrappers CSS et JS autour de chaque image, et le budget de performance est déjà épuisé avant même de parler de format.

La correction passe par trois leviers combinés : désactiver la génération des tailles de vignette inutilisées, forcer la conversion AVIF/WebP au moment de l’upload plutôt qu’en post-traitement, et supprimer les wrappers de page builder qui ajoutent des div et des scripts autour de chaque balise img sans bénéfice pour l’utilisateur.

Mesurer avant et après : les seuils qui comptent

Un changement d’images ne se juge pas à l’œil, il se mesure avec PageSpeed Insights ou le panneau Lighthouse de Chrome, en conditions mobile simulées. Trois indicateurs à surveiller :

• LCP (Largest Contentful Paint) : sous 2,5 secondes pour être dans le vert. C’est directement l’image principale qui pèse ici.
• CLS (Cumulative Layout Shift) : sous 0,1. Un CLS élevé après une refonte des images signifie presque toujours des width/height manquants.
• Poids total des images transféré sur la page d’accueil et une fiche produit type : viser un budget sous 500 Ko à 800 Ko cumulés en dessous du fold inclus, hors hero.

Sur un site ancien qui accumule des années de contenu non optimisé, ce travail sur les images ne suffit généralement pas seul à atteindre un score mobile de 90+ : il s’accompagne souvent d’un audit plus large du thème, du JavaScript chargé inutilement et du serveur. C’est le type de diagnostic que je mène en amont d’une refonte de site web, où l’optimisation des images fait partie d’un plan de performance global plutôt que d’un correctif isolé.

Automatiser sans perdre le contrôle qualité

L’automatisation du pipeline (conversion, redimensionnement, génération du srcset) est indispensable dès qu’un site dépasse quelques dizaines de pages, mais elle ne doit jamais tourner en boîte noire. Deux points de vigilance : fixer un niveau de qualité d’encodage explicite (autour de 50-60 pour AVIF, 75-80 pour WebP, réglages à ajuster visuellement sur quelques images représentatives plutôt que de faire confiance à une valeur par défaut), et conserver les fichiers sources en haute résolution pour pouvoir régénérer les variantes si un nouveau format s’impose dans les années à venir.

FAQ

Faut-il encore générer du WebP si on sert déjà de l’AVIF ?

Oui, tant qu’une partie non négligeable du trafic vient de navigateurs ou de contextes qui ne décodent pas encore l’AVIF de façon fiable (certains navigateurs embarqués, versions anciennes sur Android bas de gamme). Le bloc <picture> avec AVIF en premier, WebP en second et JPEG en fallback couvre la quasi-totalité des cas sans complexité supplémentaire côté maintenance.

Le lazy-load ralentit-il vraiment le référencement si mal réglé ?

Indirectement, oui : le LCP et le CLS sont des signaux Core Web Vitals pris en compte dans le classement mobile de Google. Un lazy-load appliqué à l’image principale dégrade le LCP, ce qui peut faire basculer une page entière dans la catégorie “à améliorer” sur Search Console, même si le reste du site est techniquement propre.

Combien coûte la mise en place de ce genre d’optimisation sur un site existant ?

Ça dépend du volume d’images, du CMS et de l’état du thème actuel — un audit rapide permet de chiffrer précisément le travail. La meilleure approche est de demander un devis détaillé avec un diagnostic de performance inclus plutôt que d’estimer à l’aveugle.