Le lazy loading tue-t-il vraiment votre LCP ?

Pourquoi le lazy loading pose-t-il problème sur le LCP ?

Le Largest Contentful Paint mesure le temps nécessaire pour afficher l'élément visuel le plus imposant dans le viewport initial. Si cet élément — souvent une image hero ou une bannière — est en lazy loading, le navigateur attend un signal JavaScript pour déclencher le chargement.

Résultat : le rendu est retardé. Le navigateur ne peut pas anticiper la ressource via le preload scanner, et le LCP se dégrade mécaniquement. Google le dit clairement — cette pratique nuit directement aux Core Web Vitals.

Tous les lazy loadings se valent-ils ?

Non. Le lazy loading natif (loading="lazy") fonctionne bien pour les images en dessous de la ligne de flottaison. Le problème survient quand on l'applique sur des ressources critiques — celles visibles dès le chargement.

Certains scripts tiers aggravent la situation en introduisant des dépendances JavaScript supplémentaires, retardant encore plus le déclenchement du téléchargement. Le delta peut atteindre plusieurs centaines de millisecondes.

Quelles sont les erreurs typiques rencontrées en production ?

La plus fréquente : activer le lazy loading via un plugin WordPress ou un thème sans configuration granulaire. L'attribut loading="lazy" est appliqué indistinctement à toutes les images, y compris celles above the fold.

Autre cas classique : les frameworks JavaScript (React, Vue) qui lazy-loadent par défaut les composants d'images sans vérifier leur position dans le viewport initial.

• Le lazy loading retarde le LCP quand appliqué sur des images visibles sans scroll
• Le navigateur ne peut pas précharger une ressource lazy via son preload scanner
• Le lazy loading natif (loading="lazy") est efficace uniquement sous la ligne de flottaison
• Les plugins et thèmes appliquent souvent le lazy loading de manière aveugle sans discernement
• Un mauvais lazy loading peut coûter plusieurs centaines de millisecondes sur le LCP

Cette recommandation change-t-elle quelque chose sur le terrain ?

Pas vraiment — c'est une confirmation officielle de ce qu'on observe depuis des mois. Les audits PageSpeed Insights signalent déjà les images LCP chargées en lazy comme un problème critique.

Ce qui est intéressant, c'est que Martin Splitt le formule de manière directe. Pas de nuance, pas de "ça dépend". Si votre plus gros élément visuel est en lazy, vous dégradez vos performances. Point.

Le lazy loading est-il encore pertinent en 2025 ?

Oui, mais uniquement avec discernement. Sur un article long avec 20 images, lazy-loader les 18 images sous la ligne de flottaison reste une excellente pratique. Ça réduit le poids initial, accélère le Time to Interactive, et améliore l'expérience mobile.

Le problème, c'est l'automatisation bête. Les CMS modernes et les builders de pages activent le lazy loading par défaut sans logique contextuelle. Résultat : on sabote le LCP pour gagner quelques Ko sur des ressources qui auraient pu attendre.

Y a-t-il des cas où lazy-loader une image above the fold reste acceptable ?

Techniquement, non. Mais en pratique, certains contextes complexifient la donne. Sur un site avec plusieurs layouts conditionnels (desktop vs mobile, A/B tests), identifier programmatiquement quelle image sera le LCP peut être coûteux en logique.

Dans ces cas, mieux vaut privilégier un preload explicite de l'image critique côté serveur, même si elle porte un attribut loading="lazy". Le preload court-circuite le lazy et garantit un chargement anticipé.

Comment identifier les images à ne jamais lazy-loader ?

Commencez par analyser votre viewport initial sur mobile et desktop. L'élément le plus imposant visuellement — souvent une image hero, une bannière produit, ou une vidéo poster — est votre candidat LCP.

Utilisez les DevTools Chrome : onglet Performance, enregistrez un chargement, et repérez l'élément marqué comme LCP dans la timeline. Si cet élément porte un attribut loading="lazy", vous avez trouvé votre problème.

Quelles actions correctives appliquer immédiatement ?

Retirez l'attribut loading="lazy" des 2-3 premières images de votre page. Sur WordPress, cela nécessite souvent de modifier le code du thème ou d'installer un plugin de gestion granulaire du lazy loading.

Ajoutez un preload explicite pour votre image LCP dans le <head> :

<link rel="preload" as="image" href="/hero.jpg">

Cela garantit que le navigateur télécharge cette ressource en priorité absolue, avant même le parsing du HTML complet.

Comment auditer l'ensemble de vos pages à grande échelle ?

Un audit manuel page par page n'est pas tenable sur un site de 500+ URLs. Utilisez des outils comme Screaming Frog avec le rendu JavaScript activé, ou Lighthouse CI intégré à votre pipeline de déploiement.

Créez des alertes automatiques si une page présente un LCP supérieur à 2,5 secondes — souvent le signe d'un lazy loading mal placé ou d'une ressource critique non optimisée.

• Identifiez l'élément LCP sur mobile et desktop via les DevTools Chrome
• Retirez loading="lazy" des 2-3 premières images above the fold
• Ajoutez un <link rel="preload"> pour votre image hero dans le <head>
• Auditez vos plugins WordPress et thèmes — désactivez le lazy loading automatique si nécessaire
• Testez systématiquement vos modifications avec PageSpeed Insights ou Lighthouse
• Surveillez le LCP en production via Chrome User Experience Report (CrUX)
• Documentez les exceptions : certaines pages nécessitent un traitement spécifique selon leur layout