Éviter le chargement différé de l’élément LCP
Le chargement différé fait gagner des octets, mais appliqué à l'élément LCP il ralentit la page. Découvrez la bonne pratique, données A/B à l'appui.
Le chargement différé (lazy loading) repousse le téléchargement d’une ressource jusqu’à ce qu’elle soit nécessaire, afin d’économiser des données et de réduire la concurrence réseau pour les éléments critiques. Devenu un standard du web en 2019, l’attribut loading= »lazy » pour les images est aujourd’hui compatible avec la plupart des navigateurs.
C’est un outil très efficace pour réduire les octets d’images inutiles. Mais utilisé à l’excès, il peut nuire à la performance. Concrètement, charger plus tôt les images de la fenêtre visible tout en différant le reste offre le meilleur des deux mondes : moins d’octets et de meilleurs Core Web Vitals. Pour le SEO, l’enjeu est direct, car le LCP fait partie des métriques évaluées par Google : voyez notre guide pour optimiser le LCP.
L’erreur que je vois le plus souvent, c’est le lazy loading appliqué en masse via un réglage de thème, image hero comprise. On croit gagner en performance et on dégrade son LCP sans s’en rendre compte. Ma règle est simple : tout ce qui est dans la fenêtre visible se charge sans différé, le reste seulement en dessous de la ligne de flottaison.
Une corrélation préoccupante avec un LCP plus lent
Le chargement différé natif des images est utilisé par environ 29 % des sites, et son adoption progresse vite, portée en grande partie par WordPress. En comparant les données réelles de CrUX, les pages qui l’utilisent affichent en moyenne un LCP plus lent que celles qui ne l’utilisent pas.
Ce constat reste corrélatif : il ne prouve pas que le lazy loading cause à lui seul la lenteur. Mais en isolant les sites WordPress pour neutraliser ce biais, le même schéma se confirme. Une étude causale était donc nécessaire pour trancher.
Le test A/B : le coupable, c'est le différé au-dessus de la ligne de flottaison
Un test A/B en laboratoire a comparé un site WordPress de démonstration avec et sans chargement différé. Le point clé : l’implémentation testée différait aussi les images situées dans la fenêtre visible, au-dessus de la ligne de flottaison, un modèle pourtant reconnu comme à éviter.
Les résultats sont nets : sur les pages d’archives, désactiver le différé améliorait sensiblement le LCP. Le différé réduit bien le nombre d’octets d’images, mais au prix d’un LCP retardé lorsqu’il s’applique aux images visibles d’emblée.
La bonne pratique : différer seulement sous la ligne de flottaison
Un correctif a alors été testé : ne différer que les images situées sous la ligne de flottaison. Les résultats sont bien plus prometteurs. Cette approche inverse complètement la régression du LCP et peut même faire un peu mieux que la désactivation totale du différé, car elle réduit la concurrence réseau autour de l’image LCP.
Mieux encore : côté octets d’images, ce correctif n’a aucun impact négatif par rapport au comportement par défaut. On conserve donc l’économie de données tout en accélérant l’affichage ; pour aller plus loin sur ce sujet, voyez comment optimiser les images. La méthode repose sur des heuristiques côté serveur pour deviner quelles images sont visibles, ce qui peut demander un ajustement fin selon les cas réels.
| Approche | Effet sur le LCP | Effet sur les octets d'images |
|---|---|---|
Différer toutes les images |
LCP retardé sur les pages d’archives |
Octets d’images fortement réduits |
Désactiver tout le différé |
LCP plus rapide |
Octets d’images plus élevés |
Différer seulement sous la ligne de flottaison |
LCP rétabli, voire amélioré |
Octets d’images préservés |
Appliquer loading= »lazy » à une image visible dès le chargement, en particulier l’élément LCP, retarde son affichage. Réservez le chargement différé aux images situées plus bas sur la page.
new PerformanceObserver((list) => {
const latestEntry = list.getEntries().at(-1);
if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
console.warn('Warning: LCP element was lazy loaded', latestEntry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});À faire
- différer les images sous la ligne de flottaison
- charger sans délai l’image LCP
- tester l’impact réel par A/B
- surveiller l’attribut loading de l’élément LCP
À éviter
- différer les images visibles d’emblée
- appliquer loading= »lazy » à l’élément LCP
- généraliser le différé sans mesure
- supposer un gain sans le vérifier
Points clés à retenir
- Le lazy loading économise des octets mais peut ralentir le LCP
- Ne différez jamais une image au-dessus de la ligne de flottaison
- Différez uniquement les images situées plus bas sur la page
- Cette règle préserve à la fois le LCP et l'économie de données
- Détectez les éléments LCP différés avec un PerformanceObserver
L’essentiel pour un chargement différé qui sert vraiment la performance.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quelle erreur d'implémentation provoquait un LCP plus lent dans le test A/B sur WordPress ?
- Utiliser l'attribut loading=lazy uniquement sur les images du bas de page
- Différer aussi les images situées au-dessus de la ligne de flottaison, dans la fenêtre visible
- Désactiver complètement le chargement différé sur tout le site
L’implémentation testée différait des images visibles dès le chargement, au-dessus de la ligne de flottaison. C’est précisément ce modèle qui dégradait le LCP.
-
Quelle bonne pratique inverse la régression du LCP liée au chargement différé ?
- Appliquer loading=lazy à l'image LCP pour économiser des octets
- Différer toutes les images de la page sans distinction
- Ne différer que les images situées sous la ligne de flottaison
Différer seulement les images sous la ligne de flottaison inverse la régression et peut même faire mieux que tout désactiver, car cela réduit la concurrence réseau.
-
Faut-il abandonner le chargement différé des images ?
- Oui, il ralentit toujours le LCP et n'apporte aucun gain
- Oui, sauf pour l'élément LCP qu'il faut au contraire différer
- Non, il reste efficace pour économiser des octets, mais il ne doit pas viser les images visibles dès le chargement
Le chargement différé reste très utile pour économiser des octets. Il suffit de ne pas l’appliquer aux images visibles d’emblée, notamment l’élément LCP.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Vous voulez vérifier que votre chargement différé ne pénalise pas votre image principale ?