Faut-il vraiment bannir le lazy loading des images hero ?

Pourquoi le lazy loading pose-t-il problème sur les images hero ?

Le lazy loading fonctionne en retardant le téléchargement des images jusqu'à ce qu'elles approchent du viewport. C'est excellent pour économiser de la bande passante et accélérer le chargement initial — sauf quand on l'applique aux images critiques.

Une image hero ou header est par définition immédiatement visible. Si elle est en lazy loading, le navigateur attend que le HTML soit parsé, que le JavaScript s'exécute, puis déclenche le chargement. Résultat : un délai inutile qui explose le Largest Contentful Paint (LCP), l'une des métriques Core Web Vitals les plus scrutées par Google.

Que se passe-t-il concrètement au niveau du navigateur ?

Quand une image est en chargement standard (sans loading="lazy"), le preload scanner du navigateur la détecte dès le parsing HTML et lance son téléchargement en parallèle. C'est rapide, efficace.

Avec loading="lazy", ce mécanisme est court-circuité. Le navigateur attend que l'image entre dans une zone de déclenchement (viewport + marge). Pour une image déjà visible au chargement, cette attente n'a aucun sens — elle ne fait que ralentir artificiellement l'affichage du contenu principal.

Quelles sont les images concernées par cette règle ?

Toute image visible above the fold, c'est-à-dire dans la portion immédiatement affichée sans scroll. Ça inclut les hero images, les bannières header, les logos de grande taille, les visuels de mise en avant produit sur une fiche.

Si l'image constitue le plus grand élément visible au chargement (ce qui est souvent le cas d'un hero), elle devient automatiquement candidate au LCP. La lazy loader, c'est s'auto-saboter.

• Above the fold = pas de lazy loading, jamais.
• Le LCP mesure le temps d'affichage du plus grand élément visible — souvent une image hero.
• Le preload scanner détecte les ressources critiques dès le parsing HTML, sauf si elles sont en lazy.
• Lazy loading sur images critiques = délai artificiel = mauvaise expérience utilisateur.
• Google recommande de réserver le lazy aux images below the fold uniquement.

Cette recommandation est-elle alignée avec ce qu'on observe sur le terrain ?

Totalement. On voit régulièrement des sites avec des LCP catastrophiques uniquement parce qu'un plugin WordPress ou un script global a appliqué loading="lazy" à toutes les images sans distinction. Le LCP passe de 1,5s à 3,5s juste à cause de ça.

Les outils comme PageSpeed Insights ou Lighthouse le signalent d'ailleurs explicitement : "Avoid lazy-loading images that are in the viewport". C'est un quick win facile — et pourtant négligé par beaucoup de sites, y compris des e-commerce de taille moyenne.

Y a-t-il des cas où cette règle mérite d'être nuancée ?

Soyons honnêtes : non, pas vraiment. Certains développeurs argumentent qu'un lazy loading conditionnel (basé sur la détection du viewport côté serveur) pourrait fonctionner. Mais c'est complexe, fragile, et ça n'apporte rien par rapport à un chargement standard.

En revanche, on peut — et on devrait — utiliser <link rel="preload"> pour forcer le navigateur à prioriser l'image hero si elle est lourde ou distante (CDN). Ça, c'est un vrai levier.

Quelle est l'erreur la plus fréquente autour de cette problématique ?

Appliquer le lazy loading au niveau global via un plugin ou une directive CSS/JS, sans aucune logique de ciblage. On lazy load tout, y compris ce qui ne devrait jamais l'être.

Deuxième erreur classique : tester son site sur desktop avec une connexion rapide, ne rien remarquer, et ne jamais vérifier le comportement mobile sur 3G. C'est là que le delta LCP explose et que l'impact devient visible dans les Core Web Vitals remontées par la CrUX (Chrome User Experience Report).

Comment identifier les images qui ne doivent jamais être en lazy ?

Lance un audit PageSpeed Insights ou WebPageTest sur tes pages clés (home, fiches produit, landing pages). Regarde l'élément détecté comme LCP — c'est souvent une image.

Si cette image porte l'attribut loading="lazy", c'est un bug. Elle doit passer en loading="eager" (ou sans attribut, c'est équivalent). Bonus : ajoute un <link rel="preload" as="image" href="..."> dans le <head> pour forcer sa priorisation.

Quelles actions concrètes mettre en place immédiatement ?

D'abord, audite ton site pour repérer toutes les images above the fold actuellement en lazy. Inspecte le code source, utilise les DevTools (onglet Network), regarde les attributs loading.

Ensuite, modifie le comportement : désactive le lazy sur ces images spécifiques. Si tu utilises un CMS (WordPress, Shopify, etc.), vérifie les réglages du thème et des plugins d'optimisation. Beaucoup ont une option "exclure les X premières images" — utilise-la.

• Identifier l'élément LCP via PageSpeed Insights (section "Diagnostics").
• Vérifier si cet élément porte loading="lazy" dans le code source.
• Retirer l'attribut loading="lazy" ou le remplacer par loading="eager".
• Ajouter un <link rel="preload"> pour l'image hero si elle est lourde ou distante.
• Tester le LCP avant/après sur mobile avec throttling 3G (WebPageTest).
• Configurer les plugins/thèmes pour exclure automatiquement les images above the fold du lazy loading.
• Surveiller les Core Web Vitals dans la Search Console pour valider l'amélioration sur 28 jours.

Et si mon site utilise un framework JS moderne ?

Les frameworks comme Next.js, Nuxt, Gatsby ont leurs propres composants Image avec lazy loading activé par défaut. Il faut explicitement désactiver ce comportement pour les images critiques.

Sur Next.js : <Image priority />. Sur Nuxt : loading="eager". Consulte la doc de ton framework — cette option existe toujours, mais elle n'est pas mise en avant.