Faut-il vraiment arrêter de lazy-loader toutes vos images ?

Pourquoi Google s'oppose-t-il au lazy-loading généralisé ?

Le lazy-loading est une technique de chargement différé des images qui permet de ne télécharger que les ressources visibles à l'écran. L'idée est séduisante : pourquoi charger une image que l'utilisateur ne verra peut-être jamais ? Sauf que cette logique se retourne contre vous quand elle s'applique aux images immédiatement visibles.

Lorsque vous lazy-loadez une image above-the-fold, vous introduisez un délai artificiel. Le navigateur doit d'abord exécuter le JavaScript qui détecte que l'image est visible, puis seulement déclencher son téléchargement. Résultat : l'utilisateur voit un espace vide pendant quelques dixièmes de seconde — voire plus sur une connexion lente.

Quels sont les impacts concrets sur les Core Web Vitals ?

Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour afficher le plus grand élément visible. Si votre image principale est lazy-loadée, son chargement est retardé, ce qui dégrade directement votre LCP. Google a été clair : un mauvais LCP pénalise votre classement.

Le Cumulative Layout Shift (CLS) peut également être affecté. Sans dimensions explicites (width/height), une image qui se charge tardivement provoque un décalage brutal du contenu. L'utilisateur commence à lire, puis tout se décale d'un coup — frustration garantie.

Où se situe exactement la ligne de flottaison ?

La ligne de flottaison (fold) désigne la limite basse de ce qui est visible sans scroller. Sauf qu'elle varie selon l'appareil, la résolution, l'orientation de l'écran. Un smartphone en portrait n'a pas le même viewport qu'un desktop 27 pouces.

Concrètement, considérez que les 600 à 800 premiers pixels en hauteur sont above-the-fold pour la majorité des écrans mobiles. Au-delà, le lazy-loading devient pertinent. Mais attention : une hero image, un logo, une bannière principale doivent toujours se charger immédiatement.

• Le lazy-loading généralisé dégrade le LCP et l'expérience utilisateur
• Les images above-the-fold doivent être chargées en priorité
• La ligne de flottaison varie selon les appareils
• Les Core Web Vitals sont directement impactés par une mauvaise gestion du lazy-loading
• Le CLS augmente si les dimensions des images ne sont pas spécifiées

Cette recommandation est-elle cohérente avec les pratiques observées ?

Oui, et c'est même un retour à la raison après des années d'excès. Beaucoup de CMS et de thèmes WordPress ont implémenté le lazy-loading par défaut sur toutes les images, sans distinction. Résultat : des sites avec des LCP catastrophiques, parfois au-delà de 4 secondes.

On observe régulièrement des audits où la hero image d'un site e-commerce est lazy-loadée. Le produit vedette met 2 secondes à s'afficher sur mobile. L'intention était bonne (économiser de la bande passante), mais l'effet est désastreux pour la conversion et le SEO.

Quelles nuances faut-il apporter à cette règle ?

La déclaration de Martin Splitt est claire mais manque de précision sur comment identifier automatiquement les images above-the-fold. [À vérifier] : Google ne fournit pas de méthode standardisée pour déterminer dynamiquement quelles images sont visibles au chargement initial.

Certains frameworks modernes (Next.js, Nuxt) intègrent des mécanismes de détection, mais ils reposent sur des heuristiques. Si votre layout est conditionnel (différent selon l'appareil, l'utilisateur connecté, etc.), ces heuristiques peuvent échouer. Dans ce cas, mieux vaut pécher par prudence et ne pas lazy-loader les 3 à 5 premières images.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous avez une page de galerie d'images avec 200 visuels, il serait absurde de tout charger d'un coup. Le lazy-loading reste indispensable. Mais même là, les premières lignes de vignettes doivent se charger immédiatement.

Sur les pages AMP, le lazy-loading est géré nativement par le format lui-même, avec des règles optimisées. Vous n'avez pas besoin de l'implémenter manuellement. Laissez AMP gérer cette partie.

Que faut-il faire concrètement pour corriger ce problème ?

Commencez par auditer vos pages stratégiques : homepage, pages produits, pages catégories. Identifiez les images qui se chargent immédiatement à l'écran (hero, logo, première image produit). Ces images ne doivent pas avoir l'attribut loading="lazy".

Si vous utilisez WordPress, vérifiez les réglages de votre thème et de vos plugins d'optimisation (WP Rocket, Imagify, etc.). Beaucoup proposent une option pour exclure les X premières images du lazy-loading. Activez-la.

Comment identifier les images above-the-fold sur un site complexe ?

Utilisez les outils de développement de Chrome. Ouvrez l'onglet Performance, lancez un enregistrement, rechargez la page. Identifiez visuellement quelles images apparaissent avant tout scroll. Ce sont celles-ci qu'il faut charger en priorité.

Pour automatiser, certains outils comme Lighthouse CI ou WebPageTest peuvent détecter les images LCP. Si votre image LCP est lazy-loadée, vous verrez un avertissement explicite dans le rapport.

Quelles erreurs éviter lors de la mise en œuvre ?

Ne supprimez pas le lazy-loading partout. Ce serait revenir au problème inverse : pages trop lourdes, temps de chargement global dégradé. Le lazy-loading reste une technique essentielle pour les images below-the-fold.

Ne vous fiez pas uniquement aux dimensions du viewport. Testez sur plusieurs appareils réels. Un pliable, un tablet en mode paysage, un écran ultra-wide — chacun a sa propre définition de la ligne de flottaison.

• Supprimer l'attribut loading="lazy" des images above-the-fold
• Définir explicitement les attributs width et height pour éviter le CLS
• Utiliser fetchpriority="high" sur l'image LCP pour forcer son chargement prioritaire
• Tester le LCP avec Lighthouse et PageSpeed Insights après modification
• Vérifier que les plugins d'optimisation respectent ces exclusions
• Auditer régulièrement les pages critiques (homepage, produits phares)
• Documenter les règles de lazy-loading dans votre guide de développement