Sommaire
Dans l’épisode 98 de Search Off the Record, John Mueller et Martin Splitt de l’équipe Google Search ont abordé en détail le lazy loading et ses implications SEO. Voici les points clés de leur discussion.
Qu’est-ce que le lazy loading ?
« L’idée du lazy loading est de charger les ressources uniquement quand vous en avez besoin, plutôt que de tout charger en même temps », a résumé Martin Splitt. Cette technique évite de ralentir le chargement global et économise les ressources comme la batterie et le trafic réseau.
Contrairement au chunking HTTP traditionnel qui charge progressivement les éléments, le lazy loading empêche spécifiquement le chargement d’images ou de vidéos situées en bas de page tant que l’utilisateur ne s’en approche pas.
Les avantages du lazy loading
Martin Splitt estime que « pratiquement toutes les pages peuvent bénéficier de cette technique, surtout les pages longues ». L’objectif principal est d’éviter le travail inutile : « Vous voulez éviter un travail qui ne rapporte rien. »
Cette approche devient particulièrement pertinente avec des sites complexes contenant beaucoup de contenu. Splitt donne l’exemple d’un ticker de cotations boursières : « Si vous devez payer pour les appels API que vous faites, vous pourriez en économiser quelques-uns si les gens ne scrollent pas jusqu’à ce ticker. »
L’évolution vers le natif
Historiquement, les développeurs devaient créer leurs propres solutions avec JavaScript. « Il y a eu une époque où les bibliothèques de lazy loading ont proliféré », a noté Splitt. Mais désormais, « les navigateurs ont un attribut natif pour les images et les iframes : l’attribut loading. Là, vous pouvez spécifier ‘lazy’, ce qui fait que le navigateur s’occupe du lazy loading pour vous. »
Cette évolution simplifie considérablement l’implémentation. WordPress, par exemple, utilise maintenant le lazy loading d’images par défaut grâce aux contributions de Felix Arntz de Google.
L’erreur à éviter, le lazy loading systématique
La mise en garde (importante) concerne l’application automatique du lazy loading à toutes les images. « Si chaque image est chargée en lazy loading, cela signifie que les images immédiatement visibles sont aussi chargées en lazy loading », a prévenu Splitt.
Les navigateurs ont ce qu’on appelle un scanner de ressources. Ils cherchent les images et comprennent qu’elles sont très visuelles, donc probablement très perceptibles quand elles manquent. Ils essaient donc de commencer à charger les images le plus tôt possible.
Pour une image hero en haut de page, l’attribut loading=lazy retarde inutilement le chargement, ce qui crée une expérience utilisateur dégradée.
Impact SEO et Core Web Vitals
Concernant le SEO, Google Search confirme que la performance est la préoccupation principale que le lazy loading adresse. L’impact se ressent particulièrement sur le Largest Contentful Paint (LCP) : « Si vous n’utilisez pas le lazy loading là où vous devriez, cela impactera probablement un aspect des Core Web Vitals. »
Inversement, utiliser le lazy loading sur des images immédiatement visibles aura très probablement un impact sur votre Largest Contentful Paint. C’est presque garanti.
Implications pour l’indexation
Le lazy loading natif a peu d’impact sur l’indexation. Après tout, vous avez une image avec un attribut source où l’image est liée, elle est juste chargée un peu plus tard.
Les problèmes surviennent avec les bibliothèques personnalisées : « Nous avons vu plusieurs bibliothèques de lazy loading qui utilisent un attribut comme data-source plutôt que l’attribut source. Si la bibliothèque a des problèmes, elle pourrait ne pas charger l’image du tout. »
Comment vérifier l’implémentation
Pour contrôler une implémentation de lazy loading, Splitt recommande la Search Console. Utilisez l’outil d’inspection d’URL et regardez le HTML rendu. Si le HTML rendu contient toutes les URLs d’images dans l’attribut source d’une balise image, vous serez tranquille. PageSpeed Insight peut également faire le job.
Pour les non-techniciens, Google suggère une approche pragmatique : si vous savez que vous avez du contenu spécifique pour lequel vous voulez être classé et qui est chargé en lazy loading, alors si vous n’apparaissez pas pour les requêtes pertinentes, c’est peut-être que le contenu n’est tout simplement pas là.
Lazy loading et vidéos
Les vidéos représentent un cas particulier car elles sont très gourmandes en ressources. Splitt a expliqué qu’il est souvent judicieux de « charger une image poster, puis charger la vidéo seulement quand elle devient disponible dans le viewport ».
Certains l’utilisent aussi pour des raisons de confidentialité, « ne chargeant le contenu vidéo externe que quand l’utilisateur y consent ».
Images décoratives et petites images
Pour les images décoratives comme des puces personnalisées ou de petites icône », Splitt recommande de les gérer via CSS plutôt que comme balises IMG : « Vous utiliseriez probablement CSS pour les afficher, mais en indiquant clairement que cela n’a pas de signification sémantique. »
Il distingue clairement entre contenu sémantique et décoratif : « Si mon article parle des poissons de la Grande Barrière de Corail, alors les images des poissons ne sont pas décoratives. Elles sont explicatives et font partie du contenu principal. »
Infinite scroll vs lazy loading
Bien que liés, ces concepts diffèrent philosophiquement. Le lazy loading charge des ressources non-critiques d’une page […] tandis que l’infinite scroll charge du contenu supplémentaire et rend la page infinie en termes de contenu.
Pour résumer
L’équipe Google recommande donc d‘utiliser l’attribut loading="lazy" natif pour la plupart des cas d’usage. Les bibliothèques personnalisées restent pertinentes pour des besoins spécifiques comme le chargement progressif (basse puis haute résolution) ou le lazy loading d’éléments autres que les images et iframes.
Pour plus d’informations, l’équipe Google renvoie vers web.dev qui contient beaucoup de documentation sur le lazy loading et vers la communauté Search Central Help pour les discussions.
