Une page e-commerce affiche 100 produits, chacun avec 3 images. C’est 300 images que le navigateur doit télécharger avant d’afficher la page. Même avec compression agressive, c’est plusieurs megabytes à télécharger. Sans lazy loading, le temps de chargement peut dépasser 10 secondes, et les visiteurs abandonnent. Avec le lazy loading, seules les images visibles se chargent immédiatement, les autres attendent que l’utilisateur scrolle vers elles. C’est une amélioration drastique de la performance utilisateur.

Le lazy loading améliore dramatiquement la performance : temps de chargement réduit, consommation de bande passante réduite, Core Web Vitals améliorés. Mais il pose une question importante pour le SEO : et Google ? Si Google ne scrolle pas votre page, il ne voit pas les images en lazy loading. Elles ne sont pas indexées, pas alt text détectés, pas inclues dans le sitemap image. Cela peut nuire à votre SEO image si la stratégie n’est pas pensée pour Google.

Chez Propuls’Lead, nous avons vu des sites perdre 30 % de leur visibilité Image Google après avoir implémenté le lazy loading sans plan SEO. Les images des premiers produits étaient indexées correctement, mais les images des produits au-delà de la fold n’étaient jamais crawlées ou indexées par Google parce que Googlebot ne scrollait pas assez loin. C’est le pire des deux mondes : pas d’amélioration de performance pour les utilisateurs (parce que tous les utilisateurs scrollent), perte d’indexation image pour Google. Cet article vous montre comment implémenter le lazy loading correctement, sans sacrifier votre SEO image.

Comment fonctionne le lazy loading

Le lazy loading consiste à différer le chargement des ressources (images, vidéos, iframe) jusqu’au moment où elles deviennent visibles à l’écran. Au lieu de charger l’image immédiatement avec ``, vous mettez une URL de placeholder et une donnée d’attribut avec l’URL réelle : ``. Un script JavaScript écoute quand l’utilisateur scrolle, détecte que l’image devient visible, et change le src pour que le navigateur la charge.

La méthode moderne utilise l’API `IntersectionObserver`. Au lieu de surveiller chaque scroll (coûteux en performance, peut générer 60 événements par seconde sur desktop), IntersectionObserver détecte quand un élément devient visible dans la fenêtre du navigateur. C’est beaucoup plus efficace. Dès que l’image entre dans une zone de tolérance (par défaut 50px avant d’être visible), le code JavaScript charge l’image réelle.

Propuls’Lead recommande l’attribut HTML natif `loading= »lazy »` sur les balises `` pour le lazy loading basique. C’est supporté par tous les navigateurs modernes (sauf Internet Explorer, mais qui s’en soucie en 2026). Syntaxe simple : ` $\"Description\"$ `. Pas de JavaScript, c’est natif au navigateur. Le navigateur gère automatiquement le chargement différé sans que vous ayez à écrire du code personnalisé. C’est l’approche la plus performante et la plus SEO-friendly parce qu’elle n’a pas de dépendances externes ou de complexité.

Le problème du lazy loading pour Google

Google crawle votre page. Il récupère le HTML. Il voit des balises `` avec `loading= »lazy »`. Deux choses peuvent arriver : (1) Google rend la page (exécute le JavaScript), détecte les images en lazy loading et les crawle aussi. (2) Google indexe juste l’HTML brut sans rendre le JavaScript, et rate les images.

Historiquement, Google ne rendait pas le JavaScript et laissait les images en lazy loading de côté. Depuis 2019, Google peut rendre le JavaScript. Mais il y a deux limitations importantes. D’abord, le rendu JavaScript consomme du crawl budget (comme vu dans notre article sur le JavaScript et SEO). Les pages qui chargent beaucoup d’images via lazy loading consomment plus de budget pour être crawlées que les pages qui chargent l’HTML purement. Pour un site e-commerce avec 1000 produits et 3000 images, c’est significatif. Google peut ne pas rendre toutes les pages à cause du coût.

Deuxièmement, si l’API `IntersectionObserver` est exécutée trop tard ou timeout, Google peut ne pas voir les images au-delà du fold. Google attend environ 5 secondes que la page se rende avant de tailler le process. Si votre IntersectionObserver se déclenche après 5 secondes (parce que le JavaScript est lent), Google ne verra pas les images.

Pour les images critically importantes (image principale du produit, hero image du site), Propuls’Lead recommande de NE PAS utiliser le lazy loading. Chargez-les en normal avec `loading= »eager »`. Pour les images secondaires (galeries additionnelles, images en dessous du fold), le lazy loading est sûr si vous respectez les bonnes pratiques décrites plus bas.

Bonnes pratiques pour le lazy loading et le SEO

Première bonne pratique : conservez la balise `alt` même sur les images en lazy loading. ` $\"Chaussures$ `. Google voit le texte alt avant de charger l’image. C’est important pour l’accessibilité et pour que Google comprenne le contenu de l’image. Les images sans alt ne sont jamais indexées efficacement par Google Images.

Deuxième : définissez les dimensions width et height sur la balise. ` $\"...\"$ `. Quand le navigateur connaît les dimensions, il réserve l’espace pour l’image avant son chargement. Cela élimine le CLS (Cumulative Layout Shift) quand l’image charge. C’est un Core Web Vital que Google mesure maintenant systématiquement. Un site avec du CLS nul est toujours mieux classé qu’un site avec du layout instable.

Troisième : utilisez des images responsives avec `srcset` si possible. ` $\"...\"$ `. Le navigateur télécharge la bonne taille selon l’écran et la densité de pixels. Sur mobile, pas besoin de charger une image 4K. Cela réduit la bande passante et améliore la performance.

Quatrième : utilisez le lazy loading natif HTML `loading= »lazy »` plutôt que les implémentations custom en JavaScript. Google comprend mieux `loading= »lazy »` que les scripts IntersectionObserver custom. C’est du HTML pur, aucune dépendance technologique. Cela va de pair avec une bonne structure technique du site et une implémentation solide du JavaScript et SEO en général.

Cinquième : testez le crawl Google. Utilisez Google Search Console « Inspection d’URL » et cliquez « Voir le rendu de la page tel que Googlebot le voit ». Regardez si Google voit vos images en lazy loading. Si vous voyez des images manquantes ou vides dans le rendu, c’est un problème : Google ne les crawle pas.

Impact sur les Core Web Vitals

Le lazy loading affecte directement les Core Web Vitals, surtout le LCP (Largest Contentful Paint). Une image en lazy loading qui se charge tardivement augmente le LCP parce qu’elle est considérée comme un contenu qui change après le rendu. Si votre LCP principal est une image lazy-loadée, le score plonge.

Propuls’Lead recommande : pour l’image du hero (première image visible), mettez `loading= »eager »` (ou omettez l’attribut, eager est le défaut). Pour les images en-dessous du fold, utilisez `loading= »lazy »`. Cela garantit que votre LCP n’est pas affecté.

Les images lazy-loadées réduisent aussi le temps de chargement initial (FCP, First Contentful Paint), ce qui améliore l’expérience utilisateur. Mais sur le papier des Core Web Vitals, ne pas lazy-loader les images critical est mieux qu’une implémentation imparfaite.

Alternative : placeholder et progressive image loading

Une alternative au lazy loading classique est le placeholder progressif. Vous chargez une minuscule version de l’image d’abord (quelques KB), puis progressivement la haute-résolution. C’est ce que font des services comme Medium ou Spotify. L’utilisateur voit une version floue très rapidement, puis elle se nettoie progressivement. L’effet perçu est que l’image se charge instantanément au lieu d’attendre.

Pour le SEO, c’est neutre. Google voit l’image finale et l’indexe correctement. Mais pour l’utilisateur, c’est psychologiquement mieux qu’une zone vide grise qui attend le chargement de l’image complète. Les taux de bounce diminuent parce que les utilisateurs ne pensent pas que la page est cassée. Propuls’Lead utilise cette technique sur les sites e-commerce haut de gamme où l’esthétique du placeholder et l’expérience utilisateur progressive comptent énormément. Le coût est légèrement plus élevé (il faut générer deux versions de chaque image), mais le bénéfice pour la conversion vaut souvent l’investissement.

Considérations pour les sitemaps images

Si vous exploitez Google Images pour du trafic, déclarez vos images dans un sitemap image XML. Google voit votre sitemap avant de crawler votre site. Si vos images sont listées dans le sitemap, Google priorise leur crawl même si elles sont lazy-loadées.

Exemple de sitemap image :

« `xml

https://example.com/product/1

https://example.com/images/product-1-main.jpg

Produit 1

Description du produit 1

« `

Les sitemaps images garantissent que Google voit vos images même en lazy loading. Pour en savoir plus sur la structure technique, consultez notre article sur les sitemaps XML et robots.txt.

Sources

Lazy loading images — Google Developers

Intersection Observer API — MDN Web Docs

Core Web Vitals et images — Web.dev

Sitemaps images pour le SEO — Google Search Central

Lazy loading et SEO : comment charger vos images en différé sans nuire à l’indexation