Faut-il vraiment éviter le lazy-loading sur toutes vos images ?

Pourquoi Google insiste-t-il sur ce point précis ?

Le lazy-loading reporte le chargement des images jusqu'à ce qu'elles soient sur le point d'entrer dans le viewport. Appliqué à une image visible dès l'arrivée sur la page, cela introduit un délai artificiel : le navigateur doit d'abord parser le HTML, charger le JavaScript, puis déclencher le chargement de l'image. Le résultat ? Un écran vide ou un espace blanc pendant quelques centaines de millisecondes.

Ce délai dégrade directement le Largest Contentful Paint (LCP), métrique Core Web Vitals qui mesure le temps de rendu du plus gros élément visible. Si votre hero image est en lazy-load, vous sabotez volontairement votre LCP.

Quelle est la ligne de flottaison exactement ?

La ligne de flottaison (ou "fold") désigne la limite inférieure de l'écran au premier chargement, avant tout scroll. Tout ce qui est visible immédiatement doit charger en priorité — images, textes, boutons.

Le problème : cette ligne varie selon les appareils. Un smartphone en portrait, une tablette en paysage, un écran desktop 27 pouces… la hauteur visible change radicalement. Les navigateurs modernes et les frameworks (WordPress, Next.js) tentent d'estimer ce seuil, mais ce n'est jamais parfait.

Quelles sont les conséquences concrètes d'un lazy-loading mal appliqué ?

• Dégradation du LCP : retard visible du chargement des images principales, impact direct sur les Core Web Vitals
• Cumulative Layout Shift (CLS) : si l'espace n'est pas réservé avec width/height, les images lazy-loadées provoquent des décalages de mise en page
• Expérience utilisateur appauvrie : écrans vides, sensation de lenteur même sur connexion rapide
• Perte potentielle de positions : les Core Web Vitals sont un signal de classement confirmé depuis 2021

Cette recommandation est-elle vraiment appliquée par les CMS et frameworks ?

Soyons honnêtes : la majorité des implémentations grand public se plantent sur ce point. WordPress, avec son attribut loading="lazy" automatique depuis la version 5.5, applique parfois le lazy-loading à des images au-dessus de la ligne de flottaison. Le CMS tente de détecter les premières images, mais se trompe régulièrement.

Les frameworks JavaScript (React, Vue, Next.js) font mieux avec leurs composants <Image> optimisés, mais encore faut-il que les développeurs les utilisent correctement. J'ai vu des sites en Next.js où toutes les images avaient loading="lazy" en dur, y compris le logo et la hero.

Quelles sont les zones grises de cette déclaration ?

Google ne précise pas combien d'images doivent charger normalement. Une seule ? Les trois premières ? Jusqu'à quelle hauteur exactement ? [A vérifier] : il n'y a pas de seuil officiel en pixels ou en nombre d'images.

Autre flou : que faire des images en carrousel visible au premier écran ? Lazy-loader la deuxième slide qui s'affichera dans 5 secondes ? La question reste ouverte. Mon conseil terrain : charger normalement la première slide, lazy-loader le reste.

Cette règle s'applique-t-elle aussi aux images de background CSS ?

Google parle explicitement des balises <img>, mais le principe vaut pour les background-image critiques. Si votre hero est un div avec un background CSS, ne le différez pas via JavaScript.

Cela dit, les navigateurs chargent les background-image CSS différemment — ils ne déclenchent le fetch que si l'élément est dans le DOM et visible. C'est déjà une forme de lazy-loading natif, mais moins pénalisante que du JS custom mal ficelé.

Comment identifier les images qui ne doivent pas être en lazy-loading ?

Utilisez PageSpeed Insights ou Lighthouse en mode mobile et desktop. Regardez la section LCP : si l'élément détecté est une image lazy-loadée, vous avez un problème. Le rapport vous dira explicitement si le lazy-loading nuit au LCP.

Inspectez manuellement votre page avec DevTools : ouvrez l'onglet Network, filtrez sur "Img", rechargez et observez l'ordre de chargement. Les premières images visibles doivent apparaître en haut de la cascade, pas après 2 secondes de parsing JS.

Quelles erreurs techniques éviter absolument ?

Ne forcez jamais loading="lazy" sur une image qui a fetchpriority="high" ou qui est marquée comme critique. C'est une contradiction flagrante qui déroute le navigateur.

Évitez les solutions JavaScript custom pour le lazy-loading si vous n'avez pas la maîtrise technique pour exclure proprement les images above-the-fold. L'API native loading="lazy" est suffisante dans 90% des cas, à condition de ne pas l'appliquer aveuglément.

• Auditer votre site avec Lighthouse/PageSpeed Insights pour détecter les images LCP lazy-loadées
• Retirer l'attribut loading="lazy" sur les 1-2 premières images visibles de chaque page
• Configurer votre CMS/plugin pour exclure les images critiques du lazy-loading automatique
• Ajouter fetchpriority="high" sur l'image LCP si le navigateur la supporte (Chrome, Edge)
• Réserver l'espace avec width et height pour éviter le CLS, même sur les images non lazy-loadées
• Tester sur mobile ET desktop : la ligne de flottaison change, donc vos exclusions aussi
• Vérifier que vos balises <picture> et srcset ne cassent pas le comportement du lazy-loading natif