Comment tester efficacement le lazy loading des images pour le SEO ?

Pourquoi le lazy loading pose-t-il un problème pour le crawl Google ?

Le lazy loading diffère le chargement des images jusqu'à ce qu'elles entrent dans le viewport ou s'en approchent. Cette technique améliore les performances perçues, mais elle complique la vie de Googlebot si elle est mal implémentée.

Googlebot ne scrolle pas automatiquement comme un utilisateur. Si vos images critiques dépendent d'un scroll pour se charger et que vous n'avez pas implémenté l'attribut loading="lazy" correctement, elles risquent de ne jamais être vues par le bot. Résultat : absence d'indexation dans Google Images et perte de contexte pour le contenu de la page.

Que recommande concrètement Martin Splitt ?

Splitt suggère d'utiliser les DevTools du navigateur pour vérifier le comportement de chargement. L'onglet Network permet de voir quand chaque image se charge et si elle est bien visible pour le moteur. C'est une approche manuelle efficace pour quelques pages tests.

Pour une vérification à grande échelle, il évoque Puppeteer (un outil de headless browser automation) ou d'autres outils de test automatisés. Il reconnaît lui-même que cette approche est complexe — ce qui laisse entendre que Google n'offre pas d'outil clé en main pour ce diagnostic.

Quelles sont les implications pour l'indexation des images ?

Si Googlebot ne voit pas vos images au moment du crawl, elles ne seront pas indexées dans Google Images. Ce n'est pas juste un problème de performance — c'est un trou dans votre visibilité SEO.

Les images qui apportent du contexte sémantique (comme les infographies, les schémas explicatifs, les photos de produits) doivent être visibles immédiatement. Le lazy loading ne doit s'appliquer qu'aux images en dessous de la ligne de flottaison et jamais aux contenus critiques above the fold.

• Googlebot ne scrolle pas — les images lazy-loadées sans attribut natif risquent d'être invisibles
• L'attribut loading="lazy" est reconnu par les navigateurs modernes et Googlebot depuis 2020
• Les images critiques doivent toujours se charger sans condition (pas de lazy loading)
• Tester avec DevTools Network + Lighthouse est un minimum — l'automatisation avec Puppeteer reste complexe
• L'absence d'indexation dans Google Images peut impacter le trafic global, surtout pour l'e-commerce

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, et c'est d'ailleurs un problème récurrent observé sur des sites qui ont implémenté du lazy loading JavaScript custom sans tenir compte des contraintes du crawl. Les audits techniques montrent régulièrement des images produits ou des visuels clés absents de l'index Google Images alors qu'ils sont parfaitement visibles pour un utilisateur.

La nuance que Splitt n'aborde pas frontalement : Googlebot exécute JavaScript, certes, mais avec un budget de rendu limité et parfois des délais qui ne permettent pas de capturer toutes les images différées. Les scripts qui attendent un scroll event ou un IntersectionObserver ne se déclenchent pas toujours comme prévu. [A vérifier] : Google n'a jamais publié de données claires sur le taux de réussite du rendu JavaScript pour les images lazy-loadées avec des librairies tierces.

Pourquoi Splitt mentionne-t-il la complexité de Puppeteer ?

Parce qu'il sait très bien que peu d'équipes SEO ont les ressources techniques pour scripter des tests à grande échelle avec Puppeteer. C'est un aveu implicite : Google ne fournit pas d'outil officiel pour diagnostiquer ce problème à l'échelle d'un site.

Lighthouse et PageSpeed Insights donnent des indications sur les images non lazy-loadées (qui ralentissent le chargement initial), mais l'inverse — détecter les images critiques mal lazy-loadées — n'est pas couvert. Tu dois bricoler ta propre solution ou passer en revue manuellement les pages clés. Pour un site de 10 000 produits, c'est ingérable sans automatisation.

Quelles erreurs critiques faut-il absolument éviter ?

La plus courante : appliquer le lazy loading de manière indifférenciée à toutes les images, y compris celles du header, du logo, de la bannière principale et de la première image produit. Ces éléments doivent se charger immédiatement, sans condition.

Autre piège : utiliser une librairie JavaScript de lazy loading qui remplace l'attribut src par data-src et ne fournit pas de fallback pour les bots. Googlebot peut interpréter le JavaScript, mais si le script plante ou tarde, l'image reste invisible. L'attribut natif loading="lazy" est compris par Googlebot et constitue la méthode la plus fiable — mais il n'est pas rétrocompatible avec tous les anciens navigateurs, d'où le besoin de stratégies hybrides.

Comment vérifier que vos images sont bien visibles par Googlebot ?

Première étape : ouvrir les DevTools (F12), onglet Network, filtrer sur "Img", puis recharger la page. Regardez quelles images se chargent immédiatement et lesquelles apparaissent seulement après un scroll. Les images above the fold doivent toutes se charger sans interaction.

Ensuite, testez la page avec l'outil d'inspection d'URL de la Search Console. Cliquez sur "Tester l'URL en direct", puis "Afficher la page testée" pour voir le rendu tel que Googlebot l'a capturé. Si des images critiques manquent, vous avez un problème de lazy loading mal configuré. C'est le test le plus rapide et le plus fiable pour un diagnostic ponctuel.

Quels outils utiliser pour une vérification à grande échelle ?

Pour automatiser, Screaming Frog peut rendre le JavaScript et comparer les images détectées avec et sans rendu. Mais cela ne simule pas parfaitement Googlebot. Les outils comme OnCrawl ou Botify peuvent croiser les logs serveur avec les données de crawl pour repérer les images jamais appelées par Googlebot.

Si vous avez les compétences techniques, Puppeteer ou Playwright permettent de scripter un parcours de plusieurs centaines de pages, de prendre des screenshots et de lister les ressources chargées. C'est puissant, mais ça demande du développement et de la maintenance. Pour beaucoup d'équipes, c'est hors de portée sans accompagnement.

Que faire si vous détectez des images critiques mal lazy-loadées ?

Excluez immédiatement les images above the fold du lazy loading. Si vous utilisez une librairie JavaScript, configurez des classes CSS d'exclusion ou des sélecteurs spécifiques. Si vous utilisez l'attribut natif loading="lazy", retirez-le des images prioritaires et ajoutez fetchpriority="high" sur l'image principale.

Relancez un crawl Google via la Search Console après correction, puis surveillez l'indexation dans Google Images. Le délai peut être de quelques jours à plusieurs semaines selon la fréquence de crawl de votre site. Gardez un œil sur les Core Web Vitals : retirer le lazy loading de certaines images peut impacter le LCP si vous ne compensez pas par d'autres optimisations (compression, CDN, responsive images).

• Vérifier manuellement les pages clés avec DevTools Network et l'outil d'inspection d'URL
• Exclure toutes les images above the fold du lazy loading
• Utiliser l'attribut natif loading="lazy" pour les images en dessous de la ligne de flottaison
• Tester le rendu Googlebot avec Search Console après chaque modification
• Monitorer l'indexation des images dans Google Images via Search Console
• Mettre en place un monitoring régulier (mensuel minimum) pour détecter les régressions après mises à jour du site