Faut-il vraiment activer le lazy-loading sur toutes les images below-the-fold ?

Pourquoi Google insiste-t-il sur le lazy-loading des images below-the-fold ?

La logique est simple : charger une image que l'utilisateur ne verra peut-être jamais constitue un gaspillage de bande passante. Sur mobile notamment, où la connexion peut être limitée, chaque octet compte.

Google valorise depuis des années les sites qui optimisent leur temps de chargement initial. Le lazy-loading des images situées hors du viewport initial permet de concentrer les ressources sur ce qui est immédiatement visible — ce qui impacte directement le LCP (Largest Contentful Paint).

Qu'est-ce que signifie concrètement "below-the-fold" ?

Il s'agit de toutes les images qui ne sont pas visibles sans scroller lors du premier affichage. Sur desktop, la ligne de flottaison se situe généralement autour de 768px de hauteur, mais cela varie selon les résolutions.

Sur mobile, cette zone est encore plus restreinte. Une image placée à 400px du haut de page peut déjà être considérée comme below-the-fold sur un smartphone. Le terme "probablement pas immédiatement visibles" laisse une marge d'interprétation — et c'est là que ça se complique.

Quels sont les bénéfices réels pour le SEO ?

L'impact se mesure sur plusieurs dimensions. Premièrement, la réduction du poids initial de la page améliore le temps de chargement perçu et les métriques Web Vitals, notamment le LCP et le FID.

Deuxièmement, moins de requêtes HTTP simultanées signifie moins de congestion réseau et une meilleure réactivité globale. Troisièmement, sur des connexions limitées ou des forfaits data restreints, l'utilisateur consomme moins de données — ce qui améliore l'expérience utilisateur.

• Amélioration du LCP en priorisant le contenu above-the-fold
• Réduction du poids initial de la page et de la bande passante consommée
• Meilleure expérience utilisateur sur mobile et connexions lentes
• Moins de congestion réseau au chargement initial
• Impact indirect sur le SEO via les Core Web Vitals et les signaux UX

Cette recommandation est-elle aussi simple qu'elle en a l'air ?

Non. Et c'est précisément là que le diable se cache. Martin Splitt parle d'images "probablement pas immédiatement visibles" — mais ce "probablement" ouvre une zone grise. Certains sites affichent des images à 600px qui restent visibles sans scroll sur de grands écrans.

La mise en œuvre native avec loading="lazy" repose sur des seuils de déclenchement définis par le navigateur, pas par vous. Chrome, par exemple, charge les images lazy environ 1250px avant qu'elles n'entrent dans le viewport — ce qui peut sembler agressif ou au contraire insuffisant selon le contexte.

Quels sont les risques concrets d'une mauvaise implémentation ?

Appliquer aveuglément le lazy-loading à toutes les images below-the-fold peut dégrader l'expérience utilisateur. Si vous lazy-loadez une image située à 500px et que l'utilisateur scrolle rapidement, il verra un placeholder vide le temps que l'image se charge.

Pire : sur certains templates, l'image LCP elle-même peut se retrouver légèrement below-the-fold sur certaines résolutions. Si vous la lazy-loadez, vous retardez artificiellement votre LCP — exactement l'inverse de l'objectif recherché. [À vérifier] sur chaque template, chaque device.

Google Discover et les crawlers voient-ils toutes les images lazy-loadées ?

Théoriquement oui, Google indexe les images en lazy-loading sans problème — c'est confirmé depuis des années. Mais sur le terrain, certains sites rapportent une indexation partielle ou retardée pour des images très loin dans le DOM.

Concrètement ? Si vous avez 50 images lazy-loadées dans un long article, Googlebot va toutes les voir — mais leur priorité d'indexation peut varier. Pour des contenus critiques (images produits, visuels éditoriaux prioritaires), mieux vaut ne pas trop compter sur le "probablement".

Que faut-il faire concrètement sur son site ?

Commencez par identifier la ligne de flottaison de vos templates principaux sur mobile et desktop. Utilisez Chrome DevTools pour simuler différentes résolutions et repérer quelles images sont réellement visibles sans scroll.

Ensuite, ajoutez l'attribut loading="lazy" uniquement sur les images situées au-delà de cette zone — typiquement à partir de la 3ème ou 4ème image dans le flux. Ne touchez jamais aux images du hero, du header, ou du premier contenu visible.

Enfin, testez les Core Web Vitals avant et après implémentation. Si votre LCP se dégrade, c'est que vous avez lazy-loadé une image critique. Revenez en arrière sur celle-ci et ajustez.

Quelles erreurs éviter absolument ?

Première erreur classique : lazy-loader l'image LCP. C'est la catastrophe annoncée. Deuxième erreur : appliquer le lazy-loading via JavaScript alors que l'attribut HTML natif suffit — vous ajoutez de la complexité inutile et du risque de régression.

Troisième erreur : ne pas définir de dimensions explicites (width/height) sur les images lazy-loadées. Sans cela, le navigateur ne peut pas réserver l'espace nécessaire, ce qui provoque du Cumulative Layout Shift (CLS) — une autre métrique Web Vitals critique.

• Identifier la ligne de flottaison sur mobile et desktop pour chaque template
• Ajouter loading="lazy" uniquement aux images below-the-fold
• Ne jamais lazy-loader l'image LCP ou les images du hero
• Définir width et height sur toutes les images pour éviter le CLS
• Tester les Core Web Vitals avant/après avec PageSpeed Insights et Search Console
• Vérifier l'indexation des images lazy-loadées dans Google Images
• Simuler des connexions lentes (3G) pour valider l'expérience utilisateur