par Le lazy loading est devenu un réflexe. On l’active partout, sur toutes les images, avec l’idée qu’un navigateur qui charge moins vite est un navigateur plus rapide. Sauf que la première image visible, celle que Google mesure en priorité, n’a rien à gagner à attendre. Lui imposer un report de chargement revient à retarder le seul élément que l’internaute regarde en arrivant. Les chiffres existent, ils sont publics, et ils racontent une histoire assez différente de la bonne intention de départ.
Ce que mesure vraiment le LCP sur une page d’accueil
Le Largest Contentful Paint chronomètre le moment où le plus gros élément visible se dessine à l’écran. Sur la grande majorité des sites, cet élément est une image : le Web Almanac 2025 de HTTP Archive relève une image comme candidat LCP sur 85,3 % des pages desktop et 76 % des pages mobiles.
Autrement dit, quand on parle du LCP d’une page d’accueil classique, on parle presque toujours du visuel principal, celui qu’on place en haut pour accrocher l’œil. Le travail technique sur scoma-consulting.com commence souvent par cette vérification simple : quel élément le navigateur a-t-il réellement élu comme LCP, et à quel moment apparaît-il ? Tant que la réponse reste floue, toutes les optimisations qui suivent avancent à l’aveugle.
La mesure ne récompense pas la prudence, elle récompense la vitesse d’affichage. Un navigateur qui doit attendre un événement, un scroll ou une intersection avant de lancer la requête de l’image principale perd un temps qu’aucune compression ne rattrapera.
Felix Arntz et Rick Viscomi ont publié sur web.dev, le 31 mars 2022, une comparaison tirée des données HTTP Archive qui donne le ton : médiane du LCP à 3 546 ms pour les pages qui utilisent le lazy loading, 2 922 ms pour les autres. L’écart atteint 624 ms, et il ne s’explique pas par le poids des fichiers mais par le moment où le téléchargement démarre.
16 % des pages se tirent une balle dans le pied
Le problème n’a rien d’anecdotique. Le Web Almanac 2025 chiffre la prévalence : entre 16 et 17 % des pages appliquent le lazy loading à leur propre image LCP. Dans le détail, 10,4 % des pages mobiles et 11,5 % des pages desktop posent l’attribut natif loading= »lazy » sur cet élément, et 5,9 % des pages mobiles passent par une approche maison de type data-src, avec un script qui échange l’attribut au chargement. Deux méthodes, un même résultat : la requête part trop tard.
Ce qui frappe, c’est le contraste avec l’autre attribut, celui qui accélère. fetchpriority= »high » n’est présent que sur 16,3 % des pages desktop et 17,3 % des pages mobiles. On a donc à peu près autant de sites qui ralentissent volontairement leur image principale que de sites qui pensent à la prioriser. La coïncidence est cruelle, et elle dit quelque chose sur la façon dont les bonnes pratiques circulent : le lazy loading a été adopté en masse parce qu’il s’active en une ligne ou via une case cochée dans un plugin, alors que la priorisation demande de savoir quelle image compte vraiment.
Les questions à se poser devant la bannière
Avant de toucher au code, une inspection visuelle suffit souvent à repérer le candidat. Regardez votre page se charger sur un téléphone en 4G bridée, en vidant le cache. Ce que vous voyez apparaître en dernier, en haut de l’écran, est probablement le coupable.
- Est-ce que la première image de la page apparaît en même temps que le texte, ou après un blanc ?
- L’attribut loading= »lazy » est-il posé sur la bannière sans distinction.
- Quel plugin ou quel thème ajoute cet attribut, et sur quels critères ?
- Le test Lighthouse en mode mobile confirme-t-il un LCP supérieur à ce que le poids de l’image laisserait supposer ?
- Si vous coupez le lazy sur cette seule image, le chiffre bouge-t-il vraiment ?
Le cas WordPress, ou quand le thème décide pour vous
Beaucoup de sites ne choisissent pas. Un thème ou une extension active le lazy loading global, sur toutes les images, sans hiérarchie. C’est là que le bât blesse, parce que la bannière hero se retrouve traitée comme une vignette de bas de page.
Hébergeurs.eu documente un cas parlant : un thème WordPress avec lazy loading global sur la bannière donne un LCP mobile Lighthouse à 4,2 secondes. On désactive l’attribut sur cette seule image, et le LCP tombe à 1,8 seconde. Une ligne retirée, plus de la moitié du temps récupérée.
La recommandation qui découle de ce constat tient en deux attributs posés ensemble sur l’image hero : loading= »eager » et fetchpriority= »high ». Le premier dit au navigateur de ne pas attendre, le second lui dit de passer devant les autres requêtes en cours. Sur ce point, voir aussi notre article sur comment une Agence google adds à lyon améliore-t-elle le taux de conversion de mes campagnes ?.
Ça paraît banal écrit comme ça, et pourtant la combinaison reste rare sur le Web, comme le montrent les chiffres de prévalence cités plus haut. Le sujet n’est donc pas de connaître la bonne réponse, il est de l’appliquer à la bonne image, ce qui suppose d’avoir identifié laquelle.
Il faut aussi se méfier des corrections partielles. Retirer le lazy de la bannière ne sert à rien si un script de preload mal placé ou un carrousel JavaScript injecte l’image après le chargement du DOM. Le navigateur ne voit alors toujours pas la ressource au bon moment, et le gain espéré s’évapore. La vérification passe par l’onglet réseau : la requête de l’image principale doit partir dans les premières, pas après trois fichiers de police.
Une image suffit à plomber tout un site
Voilà le point que les premiers résultats de recherche effleurent sans le dire clairement. Le LCP d’une page se joue sur un seul élément, et un seul élément mal configuré suffit à faire basculer la mesure dans le rouge, quel que soit le soin apporté au reste.
Vous pouvez compresser en WebP, servir en CDN, alléger votre CSS : si la bannière attend un scroll pour se charger, elle restera lente. Les 624 ms d’écart médian mesurés par HTTP Archive ne décrivent pas une moyenne abstraite, ils décrivent ce que coûte un attribut posé au mauvais endroit.
La lecture croisée des chiffres donne une idée de l’enjeu. Entre 16 et 17 % des pages concernées, ça représente un volume considérable de sites qui perdent du temps sans le savoir, sur l’élément le plus visible de leur page d’accueil.
Et dans les cas extrêmes, ceux où le script maison ajoute une couche de latence par-dessus l’attribut natif, le facteur de retard dépasse largement le demi-seconde. On parle alors d’un LCP qui double, comme dans l’exemple WordPress cité plus haut, où l’on passe de 1,8 à 4,2 secondes.
Franchement, la correction est rarement compliquée. Elle demande surtout d’accepter que la règle générale du lazy loading souffre une exception. Toutes les images ne se valent pas aux yeux du navigateur, et celle qui occupe le premier écran mérite un traitement à part. Le reste de la page peut continuer à se charger paresseusement sans dommage, c’est même souhaitable pour le poids total.
La bonne image, chargée au bon moment
Le lazy loading reste utile, il rend juste un mauvais service quand on l’applique sans discernement à l’image que Google vient mesurer en premier. Les données sont là : 624 ms de retard médian, 16 à 17 % des pages touchées, et un cas WordPress qui divise le LCP par plus de deux quand on retire l’attribut d’une seule bannière. Une exception bien placée vaut mieux qu’une règle appliquée partout. Reste à savoir combien de sites découvriront un jour que leur lenteur venait d’une case cochée par défaut, sans qu’ils aient jamais demandé ça.
