Faut-il vraiment désactiver le lazy loading sur les images above the fold ?

Pourquoi le lazy loading peut-il nuire aux Core Web Vitals ?

Le lazy loading est une technique qui retarde le chargement des images jusqu'à ce qu'elles soient sur le point d'apparaître dans le viewport. C'est une excellente pratique pour réduire le poids initial de la page et accélérer le chargement global.

Le problème surgit quand cette technique s'applique aux images above the fold — celles visibles sans scroller. Le navigateur doit d'abord parser le HTML, exécuter le JavaScript du lazy loading, puis seulement charger l'image. Ce délai rallonge artificiellement le Largest Contentful Paint (LCP), une métrique essentielle des Core Web Vitals.

Que signale exactement Lighthouse maintenant ?

Les versions récentes de Lighthouse détectent spécifiquement les images lazy loadées qui impactent le LCP. Si votre plus grand élément visuel — souvent le hero banner — est chargé en différé, vous verrez une alerte explicite dans votre rapport.

Cette détection automatique simplifie le diagnostic. Avant, il fallait croiser les données du champ "Performance" avec le DOM pour identifier le coupable. Maintenant, Lighthouse pointe directement le problème.

Quelle est la différence entre above et below the fold ?

L'above the fold désigne tout ce qui est visible à l'écran au premier chargement, sans interaction utilisateur. Le below the fold, c'est le reste — tout ce qui nécessite de scroller pour être vu.

Sur mobile, cette limite se situe généralement vers 600-800px de hauteur. Sur desktop, autour de 1000px selon les résolutions. Mais attention : cette frontière varie selon les appareils et les configurations. Une image à 700px peut être above the fold sur un écran 4K et below sur un smartphone.

• Lazy loading sur les images above the fold : ralentit le LCP et dégrade l'expérience utilisateur
• Lazy loading sur les images below the fold : optimise le temps de chargement initial et réduit la consommation de bande passante
• Lighthouse détecte automatiquement les images lazy qui impactent le LCP depuis les versions récentes
• La position du fold varie selon les appareils — une stratégie responsive est indispensable

Cette recommandation est-elle vraiment nouvelle ?

Non. Les experts SEO et webperf répètent ce conseil depuis l'introduction du lazy loading natif en HTML5. Ce qui change, c'est que Google officialise explicitement la pratique et que Lighthouse en fait un point de contrôle automatique.

Sur le terrain, je constate encore régulièrement cette erreur — notamment sur les sites utilisant des CMS ou des builders qui appliquent le lazy loading de manière globale, sans distinction. Un simple loading="lazy" dans un template global suffit à plomber le LCP.

Dans quels cas cette règle peut-elle être nuancée ?

Soyons honnêtes : la règle semble limpide, mais l'implémentation se complique dès qu'on sort des cas d'école. Sur une page avec plusieurs layouts conditionnels (mobile vs desktop), quelle image est réellement above the fold ? Sur un carrousel qui charge dynamiquement ses visuels, comment gérer les priorités ?

La déclaration de Google reste volontairement générique. Elle ne précise pas comment traiter les images en srcset responsive, ni le comportement attendu pour les images CSS background-image qui peuvent aussi impacter le LCP. [A vérifier] : est-ce que Lighthouse pénalise uniquement les balises <img> ou également les backgrounds CSS ?

Quelle erreur technique vois-tu le plus souvent ?

Le piège classique : des développeurs qui appliquent loading="lazy" via JavaScript sur toutes les images du DOM au chargement. Résultat : même la première image est différée. Pire, certains frameworks ajoutent cette directive automatiquement sans que l'équipe technique ne s'en rende compte.

L'autre cas fréquent — les images critiques chargées via JavaScript. Le navigateur ne peut pas les détecter lors du parsing initial, donc impossible de les précharger même sans lazy loading explicite. Le LCP explose, et Lighthouse ne comprend pas pourquoi puisque techniquement il n'y a pas de loading="lazy".

Comment identifier les images above the fold sur mon site ?

Utilisez PageSpeed Insights ou Lighthouse directement dans Chrome DevTools. La section "Diagnostics" indique précisément quelle image constitue votre LCP et si elle est lazy loadée. Testez sur plusieurs résolutions — desktop, tablette, mobile.

Pour une analyse plus fine, utilisez l'onglet "Performance" de Chrome DevTools. Lancez un enregistrement, rechargez la page, puis identifiez visuellement quel élément s'affiche en premier. Si vous voyez un délai entre le DOM Content Loaded et l'apparition de votre visuel principal, c'est probablement un problème de lazy loading.

Quelle stratégie adopter pour corriger le tir ?

Première étape : retirer le lazy loading des images hero, bannières principales et premiers visuels. Concrètement, supprimez l'attribut loading="lazy" sur ces éléments. Si votre CMS l'ajoute automatiquement, modifiez le template ou utilisez un filtre pour exclure certaines classes CSS.

Deuxième optimisation — ajoutez un preload pour l'image LCP via une balise <link rel="preload" as="image" href="..."> dans le <head>. Cette directive indique au navigateur de charger cette ressource en priorité absolue. Attention : ne préchargez qu'une seule image, sinon vous diluez la priorité.

Pour les sites avec des layouts conditionnels, la solution technique devient plus élaborée. Il faut détecter côté serveur ou via JavaScript critique quel visuel sera above the fold selon le device, puis injecter dynamiquement le bon preload. Ce type d'implémentation nécessite une expertise pointue — déléguer à une agence SEO spécialisée dans la webperf permet d'éviter les faux pas et de garantir un résultat mesurable sans mobiliser vos ressources internes pendant des semaines.

Comment vérifier que la correction fonctionne ?

Relancez Lighthouse après vos modifications. Le score LCP doit s'améliorer significativement si l'image était bien le goulot. Visez un LCP sous 2,5 secondes — idéalement sous 1,5 seconde sur mobile.

Validez également en conditions réelles avec Chrome User Experience Report (CrUX) ou la Search Console section "Signaux Web essentiels". Les données lab (Lighthouse) ne reflètent qu'un scénario contrôlé. Les métriques terrain montrent l'expérience réelle de vos utilisateurs.

• Auditer le site avec Lighthouse et identifier l'élément LCP
• Retirer loading="lazy" de toute image above the fold
• Ajouter un <link rel="preload"> pour l'image LCP principale
• Tester sur plusieurs résolutions (mobile, desktop, tablette)
• Vérifier que les images below the fold conservent bien le lazy loading
• Mesurer l'impact avec Lighthouse et valider en conditions réelles via CrUX
• Monitorer régulièrement les Core Web Vitals dans la Search Console