Le lazy loading affecte-t-il la visibilité par l'IA ? Des signaux contradictoires à ce sujet

Je vais détailler chaque type de lazy loading.

1. Lazy loading natif pour les images (loading=“lazy”) :

<img src="image.jpg" loading="lazy" alt="Description">

Impact : Généralement OK pour les robots IA.

• L’URL de l’image est dans le HTML
• Les robots voient la référence
• Ils n’ont pas besoin de “rendre” l’image pour savoir qu’elle existe

2. Lazy loading JavaScript pour les images :

<img data-src="image.jpg" class="lazy">
// JS remplace data-src par src au scroll

Impact : Potentiellement problématique.

• Sans exécution de JS, src est vide
• Les robots pourraient ne pas voir l’image
• Utilisez loading=“lazy” à la place

3. Intersection Observer pour le contenu :

observer.observe(element);
// Charge le contenu quand l’élément entre dans le viewport

Impact : Problématique pour l’IA.

• Les robots IA n’ont pas de “viewport”
• Ne scrollent pas, ne déclenchent pas l’intersection
• Le contenu peut ne jamais charger

4. Scroll infini :

Impact : Très problématique.

• Le contenu au-delà de la page initiale est invisible
• Les robots ne scrollent pas pour charger plus
• Seule la première page de contenu est visible

La règle générale :

Si le contenu nécessite une interaction ou une présence dans le viewport pour charger, il est probable que les robots IA ne le voient pas.

Le compromis performance vs visibilité IA.

Pourquoi nous faisons du lazy loading :

• Chargement initial plus rapide
• Meilleures Core Web Vitals
• Moins de bande passante pour les utilisateurs

La tension :

• Ce qui est bon pour la performance peut nuire à la visibilité IA
• Surtout le lazy loading dépendant du JavaScript

Approche recommandée :

Pour les images : Le lazy loading natif offre les deux avantages. À utiliser.

Pour le contenu : Rendez côté serveur le contenu critique. Ne lazy-loadez que :

• Le contenu secondaire en dessous de la ligne de flottaison
• Les recommandations qui ne sont pas à citer
• Les améliorations UI qui n’affectent pas le contenu indexable

La priorité :

Identifiez le contenu que vous voulez que l’IA cite. Ce contenu doit être dans le HTML initial. Le reste peut être optimisé pour la performance.

Exemple pratique :

Page d’article :

• Texte de l’article : Dans le HTML, toujours (à citer)
• Articles liés : Peut être lazy load (pas à citer)
• Commentaires : Peut être lazy load (pas à citer)
• Boutons de partage : Peut être lazy load (UI seulement)

Ce que l’on sait sur le comportement des robots IA.

GPTBot :

• Requêtes HTTP basiques
• Exécution JavaScript minimale
• Suit les liens visibles dans le HTML

ClaudeBot :

• Similaire à GPTBot
• Crawling centré sur le HTML
• Gestion limitée du contenu dynamique

PerplexityBot :

• Plus sophistiqué
• Un peu de gestion JavaScript
• Mais reste principalement centré HTML

Commun à tous :

• Pas de scroll
• Aucune simulation d’interaction utilisateur
• Traitement limité dans le temps
• Priorité au contenu HTML

L’implication :

Le contenu qui nécessite :

• Un scroll
• Des clics/interactions
• Une exécution JavaScript prolongée
• La présence dans le viewport

…est probablement invisible pour ces robots.

Stratégie de test :

1. Affichez la source de la page (pas l’inspecteur)
2. Votre contenu critique est-il là ?
3. Sinon, les robots ne le voient pas

Simple mais définitif.

Conseils d’implémentation.

Pour les nouvelles implémentations :

Images :

<img src="image.jpg" loading="lazy" alt="Description">

C’est tout. Le natif est le meilleur.

Sections de contenu :

<div class="content">
  <!-- Tout le contenu dans le HTML -->
  Texte complet de l’article ici
</div>

Ne lazy-loadez que les améliorations visuelles, pas le contenu.

Listes/grilles :

<ul class="items">
  <li>Élément 1</li>
  <li>Élément 2</li>
  <!-- Au moins 10-20 éléments dans le HTML -->
</ul>
<a href="?page=2">Charger plus</a>

Premiers éléments dans le HTML, pagination pour la suite.

Pour les implémentations existantes :

Si vous avez un lazy loading dépendant du JS :

1. Auditez les contenus concernés
2. Priorisez les contenus critiques à citer
3. Migrez ceux-ci vers du rendu serveur
4. Gardez le lazy loading pour le non critique

La vérification :

Après les changements :

curl -s https://votresite.com/page | grep "expression contenu critique"

Si c’est présent, c’est bon.

Point de vue monitoring.

Comment savoir si le lazy loading vous pénalise :

1. Consultez les données Am I Cited

• Les pages avec contenu lazy loadé sont-elles moins citées ?
• Comparez des pages similaires avec des implémentations différentes

2. Test manuel

• Demandez à une IA des infos sur les sections lazy loaded
• Connaît-elle l’information ?
• Sinon, le contenu est peut-être invisible

3. Logs serveur

• Comment les robots IA interagissent-ils avec votre site ?
• Reçoivent-ils des réponses complètes ?

Constats :

Les sites avec beaucoup de lazy loading (surtout scroll infini) :

• 40-60% de contenu en moins visible pour l’IA
• Taux de citation plus bas pour ce contenu
• Résolu après implémentation SSR/pagination

Sites avec lazy loading d’images uniquement :

• Pas d’impact significatif
• Le natif loading=“lazy” fonctionne bien

La recommandation :

Auditez, testez, surveillez. Ne partez pas du principe que votre implémentation est adaptée. Vérifiez-le.

Plan d’action clair maintenant.

Ce que nous gardons :

• Lazy loading natif pour les images – pas de souci

Ce que nous changeons :

Sections Intersection Observer :

• Migration du contenu critique dans le HTML initial
• Lazy loading uniquement pour l’UI

Pages à scroll infini :

• Ajout de pagination
• 20 premiers éléments dans le HTML
• Bouton “Charger plus” pour la suite

Approche de test :

1. Curl des pages après modifications
2. Vérifier que le contenu critique est dans le HTML
3. Suivre la visibilité IA avec Am I Cited
4. Comparer les taux de citation avant/après

Le principe : Contenu à citer par l’IA = toujours dans le HTML Le reste = peut être optimisé performance

Merci pour la clarté technique !