Coucou, c’est encore moi !
Bon, il est possible qu’une erreur se soit glissée dans mon mail précédent.
Dans ma précédente newsletter, je t’explique comment améliorer les core web vitals. Mais je suis allée un peu vite en besogne au moment de parler du LCP et ça peut te faire faire une bétise. Alors, me voilà, me confondant en excuses et revenant avec une explication plus précise (et un paquet de cookies tout juste sortis du four).
Reprenons :
Le LCP mesure le temps qu’il faut pour afficher le plus gros élément visible à l’écran. En général, c’est une image, un titre ou une vidéo. Plus ce temps est court, mieux c’est : un bon LCP donne l’impression d’un site rapide et fluide. Un mauvais LCP, c’est comme attendre son café trop longtemps… l’utilisateur s’impatiente et risque de partir.
Dans la newsletter, je recommandais d’utiliser le lazy loading (chargement différé) pour améliorer le LCP. Mais… ce n’est pas vraiment une bonne idée.
Lazy load et LCP : une combinaison risquée 🚨
Le lazy loading est une technique qui permet de ne charger les images que lorsque l’utilisateur commence à les voir. C’est très utile pour les images situées plus bas dans la page, car ça allège le poids du chargement initial.
Mais si l’image principale de la page (celle mesurée par le LCP) est en lazy load, elle ne sera pas chargée immédiatement. Résultat ? Le navigateur attend avant d’afficher cet élément clé, et le LCP devient plus lent au lieu de s’améliorer.
La bonne approche 🔥
✅ Ne pas appliquer le lazy load sur l’image LCP : elle doit être chargée dès l’ouverture de la page.
✅ Précharger cette image pour que le navigateur la traite en priorité.
✅ Compresser tes images (WebP, AVIF) pour réduire leur poids sans perte de qualité.
✅ Utiliser le lazy loading uniquement sur les images secondaires, celles qui ne sont pas visibles immédiatement.
En bref : le lazy load, c’est top, mais pas pour les images critiques au chargement de la page.
Voilà, je retourne me flageller et je te souhaite une bonne journée !