Vous avez installé le lazy loading sur votre image de bannière, persuadé de gagner en performance, et votre LCP a grimpé au lieu de descendre. Le paradoxe est classique et il s’explique simplement : vous avez retardé le chargement de l’élément que le navigateur devait afficher en priorité. Le lazy loading n’est pas une potion magique à verser sur toutes vos images, c’est un outil de report qui ne doit toucher que ce qui n’est pas visible au premier regard. Comprendre pourquoi le haut de page s’en trouve pénalisé change la façon dont on câble une page.

Pourquoi le lazy loading étouffe le LCP

Le LCP mesure le moment où le plus gros élément visible s’affiche à l’écran. Sur une page d’accueil, c’est presque toujours une image de héros, large, lourde, celle qu’on voit dès l’ouverture. Quand vous ajoutez loading= »lazy » sur cette image, le navigateur la traite comme secondaire : il attend que le viewport la croise avant de lancer la requête, ou plutôt il la relègue derrière d’autres ressources qu’il juge prioritaires.

Le résultat est mécanique. Le téléchargement démarre tard, la métrique enregistre ce retard, et vous avez fabriqué de vos mains le problème que vous vouliez traiter. Selon WebPerf Snippets, le lazy loading d’images above the fold figure parmi les anti-patterns de performance les plus répandus, et l’impact sur le Largest Contentful Paint peut être lourd. Pour qui creuse le sujet côté mystpi.com, le diagnostic tient souvent en une ligne : mauvaise image, mauvais traitement.

Erwin Hofman l’avait écrit dès un article du 16 juillet 2021 : les images situées above the fold ne doivent pas être chargées en lazyload. La consigne n’a pas pris une ride. Elle heurte de front l’habitude de coller l’attribut partout, dans un souci d’optimisation qui finit par produire l’inverse de l’effet recherché. Franchement, la plupart des dégradations de LCP que je croise sur des sites refaits viennent de là.

La règle pratique pour arbitrer dans le viewport

Une fois admis qu’il faut prioriser, encore faut-il savoir quoi. Toutes les images du premier écran ne se valent pas : certaines doivent se charger tout de suite, d’autres peuvent attendre sans conséquence. La nuance vient de la concurrence entre ressources, ce moment où plusieurs fichiers se disputent la bande passante et où le navigateur doit choisir lequel servir en premier.

Qui garde son chargement prioritaire

L’image la plus grande du premier écran ne doit jamais être lazyloadée. C’est elle qui portera la métrique, elle reste donc en chargement immédiat, avec éventuellement un preload et un fetchpriority élevé pour la signaler au navigateur. Le logo d’entreprise tombe dans la même catégorie : Erwin Hofman précise qu’il ne devrait pas passer par le lazyload, parce qu’il s’affiche avant tout le reste et participe à la perception d’une page vivante.

Les autres images visibles au-dessus de la ligne de flottaison, elles, peuvent être lazyloadées afin d’éviter qu’elles ne viennent concurrencer le héros dans la file d’attente réseau. On obtient alors un ordre de service clair : l’élément principal d’abord, le décor ensuite. Cette hiérarchie ne s’improvise pas, elle se décide au moment du développement et se vérifie après la mise en ligne.

Le cas des sliders

Les carrousels compliquent le tableau, surtout quand ils tournent avec Owl Carousel, TinySlider, Flickity ou Fotorama sur Magento 2. La règle est simple à énoncer : dans un slideshow, toutes les images peuvent être lazyloadées sauf la première. Celle qui occupe l’écran dès le chargement suit le même régime que le héros, les suivantes attendent leur tour, invisibles tant que l’utilisateur n’a pas cliqué. Sur ce point, voir aussi notre article sur page bloquee robots txt.

Appliquer le lazy loading à la première diapositive revient à saboter le rendu initial pour rien, puisque cette image sera de toute façon montrée. Le reste du diaporama, en revanche, retarde sans dommage. La faute classique consiste à laisser un plugin tout uniformiser sans distinction, ce qui produit exactement le mauvais résultat.

Repérer le coupable sans deviner

Beaucoup de développeurs corrigent à l’aveugle, en retirant l’attribut un peu partout jusqu’à ce que le score remonte. C’est long et ça ne garantit rien. Le snippet « Find Above The Fold Lazy Loaded Images » de WebPerf Snippets fait le travail inverse : il parcourt le viewport, repère les images portant loading= »lazy » ou un [data-src], et vous désigne le candidat LCP parmi celles qui sont mal traitées.

Concrètement, vous collez le script dans la console, vous lisez la sortie, et vous savez quelle balise retirer de la liste des paresseuses. La démarche prend une minute là où l’exploration manuelle du code en demande dix. C’est ce genre d’outil qui transforme un débat d’opinion sur les performances en une correction ciblée, sur la bonne ligne, sans toucher à ce qui fonctionne.

Les erreurs qui reviennent

Dans les audits, les mêmes confusions réapparaissent, souvent avec la meilleure intention du monde. Les repérer vite évite de perdre des heures à chercher ailleurs, alors que la cause se trouve presque toujours dans les tout premiers pixels de la page, là où le navigateur décide de son ordre de priorité et où chaque balise mal réglée pèse sur le résultat final. Un coup d’œil au-dessus de la ligne de flottaison suffit généralement à identifier le suspect.

• Mettre l’attribut lazy sur l’image de bannière sans vérifier qu’elle est bien l’élément le plus grand du premier écran.
• Le logo, traité comme n’importe quelle vignette alors qu’il s’affiche tout de suite.
• Un slider dont la première diapositive attend le scroll pour se charger, ce qui vide le haut de page pendant un instant.
• Coller l’attribut sur toutes les images du site, puis s’étonner que la métrique de chargement se dégrade.
• Ne pas contrôler ce que la console signale avant de déployer en production.

Charger d’abord, différer ensuite

Le lazy loading n’a rien d’un réglage universel qu’on active pour cocher une case dans un audit. Sur l’image qui porte le LCP, il coûte plus qu’il ne rapporte, et c’est vrai sur une page d’accueil comme sur une fiche produit avec carrousel. Prioriser le héros et le logo, différer le reste du premier écran, réserver le lazy aux diapositives suivantes : la logique tient en quelques décisions prises une fois, au bon endroit du code.

Le snippet de WebPerf Snippets donne le point de départ, la suite dépend de votre capacité à ne pas traiter toutes les images de la même façon. Si votre métrique s’est dégradée après l’ajout de l’attribut, vous connaissez maintenant le premier endroit à regarder. Combien de vos pages attendent encore une correction qui prendrait cinq minutes ?