Lazy loading
Alléger une page sans dégrader le LCP : ce qu’il faut différer, ce qu’il ne faut jamais différer.
Le lazy loading (chargement diffère) reporte le téléchargement des images hors écran. L’attribut HTML loading= »lazy » applique ce report au niveau du navigateur, sans JavaScript. En SEO, le lazy loading allege la page initiale mais degrade le LCP s’il touche une image au-dessus de la ligne de flottaison.
Comment fonctionne le lazy loading ?
Le lazy loading repose sur l’attribut HTML loading= »lazy », ajoute aux balises image et iframe. Le navigateur lit cet attribut, puis diffère le téléchargement jusqu’à l’approche du viewport. Chrome, Firefox et Safari déclenchent le chargement quelques centaines de pixels avant l’entrée a l’écran. Avant cette API native, le report passait par des librairies JavaScript comme lazysizes ou l’API Intersection Observer. Selon Google (web.dev), l’attribut natif supprime le besoin d’une librairie externe dans la majorité des cas. La valeur par défaut d’une balise image reste loading= »eager », qui telecharge le visuel des sa découverte dans le HTML.
Pourquoi le lazy loading est important pour le SEO ?
Le lazy loading influence le SEO via les Core Web Vitals, en priorité le LCP et l’INP. Bien applique, le lazy loading réduit la bande passante mobilisée au chargement initial et libere des ressources pour l’image principale. Selon Google (web.dev), les pages avec lazy loading affichent pourtant un LCP médian de 3 546 ms au 75e percentile. Les pages sans report tombent a 2 922 ms sur le même échantillon. L’écart provient des implémentations qui different des images visibles d’entrée. Le risque SEO majeur reste l’indexation : Googlebot ne voit une image que si son URL figure dans l’attribut src du HTML rendu.
| Critère | Lazy loading natif | Librairie JavaScript |
|---|---|---|
| Dépendance JavaScript | Aucune | Script requis |
| Lecture par Googlebot | URL dans l’attribut src | Risque data-src non lu |
| Controle avance (seuils, transitions) | Limite | Fin |
| Poids ajoute a la page | Zéro | JavaScript supplémentaire |
Le lazy loading est-il bon pour le SEO ?
Le lazy loading est bon pour le SEO quand il ne concerne que les images sous la ligne de flottaison. Applique au-dessous du pli, le lazy loading allege la page et économise de la bande passante mobile. Applique a l’image LCP, il retarde l’affichage principal et penalise les Core Web Vitals. Google recommande le chargement immédiat (loading= »eager ») pour les visuels visibles des l’ouverture.
Comment activer le lazy loading sur WordPress ?
WordPress ajoute l’attribut loading= »lazy » automatiquement aux images de l’éditeur de blocs depuis la version 5.5. Aucune action manuelle n’active le lazy loading natif sur un contenu standard. Pour exclure une image critique, un thème ou un filtre wp_img_tag_add_loading_attr retire l’attribut sur le visuel choisi. Selon Google (web.dev), WordPress épargne le report sur la première image du contenu principal pour protéger le LCP.
Exemple concret de lazy loading
Un exemple concret oppose une image hero mal configurée a sa version corrigée. La première porte loading= »lazy » alors qu’elle est visible d’entrée, ce qui retarde le LCP. La version corrigée retire l’attribut et ajoute fetchpriority= »high », ce qui priorise le téléchargement. Une image placée sous le pli garde loading= »lazy » de façon légitime.
<img src="/img/hero.webp" fetchpriority="high" width="1200" height="600" alt="Visuel principal"><img src="/img/section-8.webp" loading="lazy" width="800" height="600" alt="Illustration bas de page">Erreur fréquente observée en audit
Cas réel. Sur lemag.promovacances.com, le réglage du lazy loading via LiteSpeed Cache risquait de différer des images visibles dès l’ouverture de la page, dont le visuel principal susceptible de devenir l’élément LCP. La correction a consisté à activer la détection des images présentes dans le viewport et à exclure les visuels de type hero, bannière ou image mise en avant. Les images situées sous la ligne de flottaison ont conservé l’attribut loading="lazy".
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Google, web.dev, The performance effects of too much lazy loading · 2022
- 2Google, web.dev, Browser-level image lazy loading · 2024
- 3MDN Web Docs, Le chargement diffère · 2026
Questions fréquentes
Quelles images ne doivent jamais être différées ?−
Celles visibles au premier affichage, en particulier l’élément LCP. Selon web.dev, le LCP médian se dégrade quand le lazy loading touche l’image principale. L’attribut fetchpriority high accélère au contraire son chargement.
Le lazy loading empêche-t-il l’indexation des images ?+
Non, quand il repose sur l’attribut HTML natif. Une implémentation JavaScript qui ne charge la source qu’au défilement rend l’image invisible au rendu. Google recommande alors une balise noscript ou l’attribut natif.
Faut-il différer aussi les iframes ?+
Oui, l’attribut loading lazy s’applique également aux iframes. Une vidéo intégrée ou une carte pèsent lourd au chargement. Le report libère la bande passante pour le contenu visible.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).