Vous avez installé le lazy loading sur votre site, tout content d'avoir coché la case "performance", et deux mois plus tard, votre trafic organique baisse. Pas de pénalité, pas de message dans la Search Console. Juste une glissade lente. J'ai vécu exactement ça sur un site de e-commerce — environ 4 000 pages produits — et j'ai mis trois semaines à comprendre que le coupable était cette foutue optimisation que tout le monde recommande.
Le lazy loading n'est pas mauvais en soi. Le problème, c'est que 90 % des implémentations que je croise sont appliquées n'importe comment, souvent par-dessus une couche de plugins qui se marchent dessus. Et Google, lui, ne fait pas de sentiment : il mesure ce qu'il voit, pas ce que vous vouliez faire.
Points clés à retenir
- Le lazy loading appliqué au-dessus de la ligne de flottaison retarde directement l'image LCP — le signal le plus lourd des Core Web Vitals.
- Un chargement différé mal configuré peut empêcher Googlebot de voir vos images et vos contenus critiques.
- L'attribut natif
loading="lazy"est plus fiable qu'un script JavaScript tiers, mais il ne pardonne pas les erreurs de placement. - Le vrai test : désactivez tout, mesurez, réactivez progressivement en observant le LCP dans la Search Console.
- Un site qui "fait du lazy loading partout" passe souvent à côté de ce qui compte : les images du premier écran.
- La question n'est pas "lazy ou pas lazy", mais "lazy sur quoi, et à quel moment".
Pourquoi le lazy loading peut nuire à votre référencement
Posez-vous une question simple : qui décide de la position de vos pages dans Google ? Un algorithme qui, entre autres choses, simule le chargement de votre page avec un navigateur headless. Chrome headless, dans un environnement de test, avec des ressources limitées. Si vos images critiques sont chargées par un script JavaScript qui attend un événement scroll, et que ce scroll ne se produit jamais… que voit Googlebot ?
Exactement. Pas grand-chose.
Le mécanisme causal, étape par étape
Voilà ce qui se passe concrètement quand vous activez du lazy loading sans réfléchir :
- Googlebot demande votre page HTML. Il la reçoit, la parse, découvre les balises
<img>. - Si vous utilisez un plugin qui remplace le
srcpar undata-srcet injecte l'image réelle via JavaScript, Googlebot doit exécuter ce JS pour voir l'image. - Ce JS s'accroche à un événement de scroll, d'intersection observer, ou à un timer. Sur une page en test, aucun scroll ne se déclenche.
- Résultat : vos images ne sont pas indexées, votre LCP se calcule sur du vide, et votre CLS explose quand l'image finit par apparaître — ou pas.
Spoiler : la Search Console ne vous le dira pas en clair. Vous verrez juste "LCP : à améliorer" sur des pages où vous n'avez rien changé d'autre.
Le cas critique : le lazy loading au-dessus de la ligne de flottaison
C'est l'erreur que j'ai commise. Et c'est la plus courante.
Sur le site dont je vous parlais, l'image du hero — celle qui occupe tout le haut de la page, celle que l'utilisateur voit en premier — avait reçu un loading="lazy" "pour gagner en performance". Logique de surface : on ne charge que ce qu'on voit. Sauf que cette image, l'utilisateur la voit immédiatement. En la différant, on a retardé de 1,8 seconde l'affichage du premier élément visuel.
Le LCP est passé de 2,1 s à 3,9 s. Google a mis deux semaines à le refléter, trois de plus pour que les classements bougent. On a perdu environ 12 % de trafic organique sur les pages catégories en deux mois. Pas un cataclysme, mais suffisamment pour que je m'en souvienne.
La règle, que je répète à qui veut l'entendre : jamais de lazy loading sur l'image LCP. Jamais. Ni sur le logo, ni sur le titre visuel, ni sur la première bannière. Tout ce qui est au-dessus de la ligne de flottaison se charge en eager, point.
L'impact réel sur l'indexation par les crawlers
Il y a une nuance que je vois rarement expliquée correctement : Googlebot exécute le JavaScript, mais avec des ressources limitées et un budget de rendu. Sur un site de 20 000 pages, chaque seconde de rendu supplémentaire représente une page de moins crawlée par minute.
Le budget de crawl, cette notion qu'on oublie
Si votre lazy loading oblige Googlebot à attendre un événement qui ne vient jamais, il finit par abandonner le rendu de la page. Il indexe alors une version dégradée : sans images, parfois sans les blocs de contenu dynamique. Pas d'erreur, pas de pénalité manuelle. Juste une page perçue comme pauvre.
Sur un site que j'ai audité l'an dernier, un client avait trois plugins de lazy loading activés simultanément. Chacun ajoutait sa propre couche de data-src. Le HTML contenait des images avec quatre attributs contradictoires. Le rendu mettait 6,3 secondes. Google avait indexé 340 pages sur 1 200 en six mois.
Voilà le vrai coût. Pas un crash. Une érosion silencieuse.
Quand le lazy loading marche vraiment
Il n'est pas question de jeter la technique. Bien utilisée, elle fait gagner du poids, du temps de rendu et de la bande passante. Mais elle doit respecter trois conditions :
- Ne s'appliquer qu'aux ressources sous la ligne de flottaison, sans exception.
- Utiliser l'attribut natif
loading="lazy"plutôt qu'un script tiers quand c'est possible — le navigateur gère mieux que n'importe quelle librairie. - Réserver un chargement eager pour tout ce qui participe au LCP, y compris les arrière-plans CSS critiques.
Et une quatrième, que j'ai apprise à mes dépens : tester chaque modification en isolation. Un changement à la fois. Toujours.
Native, plugin ou JavaScript maison : ce qui casse quoi
Il existe plusieurs manières d'implémenter le chargement différé, et elles n'ont pas les mêmes conséquences SEO. Voici ce que j'observe sur le terrain.
| Méthode | Fiabilité pour Googlebot | Risque principal | Quand l'utiliser |
|---|---|---|---|
loading="lazy" natif | Élevée — le navigateur gère seul | Mal placé = LCP dégradé | Par défaut, pour toute image hors écran |
| Plugin WordPress dédié | Variable selon le plugin | Conflits avec d'autres plugins, double lazy | Si vous ne touchez pas au code |
| Script JS personnalisé | Faible si mal codé | Googlebot ne déclenche pas le scroll | Cas très spécifiques, carrousels lourds |
| Intersection Observer API | Correcte | Nécessite un fallback <noscript> | Pages avec animations complexes |
Franchement, si vous n'avez pas de raison technique précise, restez sur le natif. C'est moins sexy, ça fait le job, et surtout ça évite les surprises.
Comment diagnostiquer et corriger le problème
La bonne nouvelle : c'est réparable. J'ai remonté le LCP du site dont je vous parlais de 3,9 s à 2,2 s en deux semaines, sans tout casser. Voilà la démarche que j'applique maintenant systématiquement.
Audit en quatre étapes
- Désactivez tout le lazy loading. Notez les métriques : LCP, CLS, position moyenne sur cinq pages types.
- Réactivez uniquement sous la ligne de flottaison. Ce que vous voyez sans scroller reste en eager.
- Vérifiez le HTML généré : un seul attribut de chargement par image, pas de doublons entre plugins.
- Contrôlez le rendu avec l'inspection d'URL dans la Search Console. Si l'image n'apparaît pas dans le rendu, Google ne la voit pas non plus.
L'étape 4 est celle que la plupart des gens zappent. C'est aussi celle qui m'a fait gagner le plus de temps une fois que j'ai compris qu'elle existait.
Les signes qui doivent vous alerter
- Le LCP se dégrade sur des pages où vous n'avez "rien changé" récemment.
- Certaines de vos images n'apparaissent pas dans la recherche par image.
- Le nombre de pages indexées stagne ou recule, sans erreur explicite.
- Le rendu de la page dans la Search Console montre des blocs vides.
Si vous cochez deux de ces cases, vous avez probablement un problème de lazy loading mal placé. Et vous n'êtes pas seul : avouons-le, on est une majorité à être passés par là.
Ce que j'en retiens, trois ans après
Le lazy loading n'est pas un ennemi du SEO. C'est un outil qui punit la paresse intellectuelle. On l'active parce qu'un article dit "c'est bon pour la performance", sans se demander quoi on diffère, où, et pour qui.
Aujourd'hui, quand je vois un site plonger dans les classements sans explication, c'est la deuxième chose que je vérifie. Juste après la balise canonical et avant les redirections. Neuf fois sur dix, il y a un loading="lazy" qui traîne là où il ne devrait pas.
Le plus vicieux, c'est que la technique fonctionne. Votre site paraît plus rapide pour l'utilisateur qui scrolle lentement. Les scores synthétiques grimpent. Puis Google recalcule, tranquillement, et vous perdez un pourcent par semaine pendant deux mois. Vous ne comprenez pas. Vous optimisez autre chose. Vous aggravez.
Alors la prochaine fois que quelqu'un vous dira "mets du lazy loading partout, c'est gratuit", posez-lui une seule question : "Et ton image LCP, elle attend quoi pour se charger ?"
La réponse, en général, ne vient pas tout de suite.