Largest Contentful Paint (LCP)

Ce que le LCP mesure vraiment

Le Largest Contentful Paint ne mesure pas un temps de chargement, il enregistre un horodatage de rendu : l’instant où le navigateur peint le plus grand élément de contenu visible dans le viewport, compté depuis le début de la navigation. La nuance n’est pas cosmétique. Une image peut être téléchargée en 400 ms et n’apparaître qu’à 3,2 s parce qu’une feuille de style bloque le rendu, ou parce qu’une police déclarée en font-display: block retient le bloc de texte candidat. L’onglet réseau dira que tout va vite, le LCP dira l’inverse, et c’est le LCP qui a raison sur ce que voit l’utilisateur.

Les éléments éligibles sont volontairement limités : les images <img>, les images à l’intérieur d’un <svg>, le poster d’une <video>, les arrière-plans déclarés en url() et les blocs de texte. Le candidat change plusieurs fois pendant le chargement, puis se fige à la première interaction utilisateur ou quand la page passe en arrière-plan. Chrome applique en plus une heuristique d’entropie qui écarte les images très grandes et très pauvres en information, typiquement un dégradé placeholder de deux kilo-octets étiré plein écran : sans ce garde-fou, il suffirait d’un aplat de couleur pour truquer la métrique.

La spécification W3C du Largest Contentful Paint a encore été mise à jour le 8 avril 2026, signe que la définition du candidat continue de bouger à la marge. La conséquence pratique est simple : l’élément LCP d’une page n’est pas une donnée stable qu’on note une fois dans un tableur, c’est une observation à re-vérifier après chaque refonte de gabarit. Un simple changement de hauteur de hero peut faire basculer le candidat d’une image vers un paragraphe, ou l’inverse, et déplacer entièrement le point de correction.

Terrain contre labo : c’est le 75e percentile qui tranche

Les seuils n’ont pas bougé et restent valables en 2026 : un LCP est bon à 2,5 s ou moins, à améliorer entre 2,5 et 4 s, mauvais au-delà de 4 s (documentation Google, web.dev). Ce qui compte, et que la moitié des audits que je lis passe sous silence, c’est la façon dont ce seuil est appliqué. Google évalue le 75e percentile des visites réelles collectées par CrUX, sur une fenêtre glissante de 28 jours dans la Search Console. Votre note dépend donc du quart le plus mal loti de vos visiteurs, pas de la médiane, et certainement pas d’un test lancé depuis un portable en fibre.

Le labo garde une fonction, mais elle est diagnostique. Lighthouse reproduit une session synthétique avec bridage réseau et processeur : il vous dit pourquoi une page peint tard, il ne vous dit pas si vous passez. La version 13 de Lighthouse, sortie le 10 octobre 2025, a d’ailleurs renommé plusieurs audits en identifiants « insight » sans toucher au calcul ni aux seuils des Vitals, ce qui a cassé quelques tableaux de bord internes interrogeant les anciens identifiants. Si votre reporting s’appuie sur ces IDs, vérifiez-le avant de conclure à une régression.

La mesure terrain sérieuse passe par l’API PerformanceObserver, en écoutant le type largest-contentful-paint avec buffered: true. Chaque entry expose startTime, renderTime, loadTime, la taille et l’élément concerné : c’est la seule façon d’attribuer un mauvais LCP à un gabarit précis plutôt qu’à un site entier. Deux points d’attention. Les ressources tierces ne renvoient un renderTime exact que si elles servent l’en-tête Timing-Allow-Origin, et web.dev a documenté qu’à partir de Chrome 133 un temps de rendu approximatif est disponible même sans cet en-tête pour les iframes cross-origin, ce qui débloque la visibilité terrain des pages chargées en publicités. Depuis le 12 décembre 2025, le LCP et l’INP sont par ailleurs mesurables en RUM sur tous les navigateurs majeurs, quand le CLS reste cantonné à Chromium. Le classement Google, lui, ne lit toujours que du Chrome.

Le poids réel du LCP dans le classement

Position ferme : le LCP est un départage, pas un levier. Google le range dans les signaux d’expérience de page, et sa documentation n’a jamais dit autre chose qu’à pertinence comparable, la page plus rapide passe devant. Les synthèses de 2026 qui chiffrent les signaux d’expérience de page à 10 ou 15 % du poids de l’algorithme recyclent une estimation que Google n’a jamais publiée : personne n’a accès à une pondération, et un LCP à 1,8 s ne rattrapera ni un contenu creux ni un profil de liens inexistant.

Cela dit, le terrain reste dégagé. Les données CrUX compilées par le Web Almanac 2025 donnent environ 62 % des pages mobiles avec un bon LCP et seulement 48 % des sites mobiles validant les trois Vitals. Une synthèse de données CrUX par origine publiée début 2026 relève 68,3 % de bons LCP, 87,1 % de bons INP, 80,9 % de bons CLS, mais 55,7 % d’origines seulement qui passent l’ensemble. Le LCP reste le Vital le plus difficile à tenir, donc celui qui départage encore quand deux pages se valent.

Sur l’impact business, les chiffres que tout le monde cite sont anciens mais restent les plus solides. L’étude Renault publiée par Google sur web.dev, menée de décembre 2020 à mars 2021 sur plus de 10 millions de visites dans 33 pays, associe une seconde de LCP gagnée à 14 points de taux de rebond en moins et 13 % de conversions en plus. Une étude de cas de mai 2026 sur un site d’actualité WordPress décrit un LCP mobile terrain passé de 5,5 s à 2,49 s, avec plus de 40 % de trafic supplémentaire sans réécriture de contenu. À lire avec la prudence d’usage : un chantier de performance s’accompagne presque toujours d’autres correctifs, et la corrélation ne vaut pas causalité.

Côté netlinking, la question qu’on me pose est mal posée. Le LCP d’une page qui vous fait un lien ne se transmet pas, il ne pondère pas le jus. Ce qui compte, c’est que le média hôte soit réellement lu et indexé, et un site qui peint en six secondes sur mobile perd ses visiteurs avant de vous en envoyer. Sur les médias éditoriaux que nous opérons en propre, le choix d’une chaîne de build statique n’a rien d’idéologique : il rend le TTFB non négociable et sort le LCP des variables à surveiller. Quand vous évaluez un support, ouvrez-le sur un mobile réel. C’est une vérification de deux minutes, faisable sur n’importe quel média d’un catalogue consultable sans inscription, et qu’aucune métrique d’autorité ne remplace.

Ce qu’on voit casser, en audit

La panne la plus fréquente tient en un attribut : loading="lazy" posé sur l’image de hero. Le composant a été écrit pour les illustrations d’article, il s’applique à tout, et le navigateur retarde volontairement la ressource qui définit justement le LCP. Le correctif inverse tient en deux réglages, fetchpriority="high" sur l’image candidate et zéro lazy au-dessus de la ligne de flottaison. Dix minutes de travail, pour l’un des gains les plus nets de tout le chantier.

Deuxième classique, le préchargement à côté de la plaque. On voit précharger un logo, une police d’icônes, un script de mesure d’audience, presque jamais la ressource qui porte le rendu. Un preload mal ciblé n’est pas neutre : il vole de la bande passante à l’élément qui compte, sur le lien le plus contraint de la session.

Les polices méritent leur paragraphe quand le candidat LCP est un bloc de texte, ce qui arrive sur la plupart des pages éditoriales sans visuel d’ouverture. Avec font-display: block, le texte reste invisible jusqu’à trois secondes et le LCP l’attend sagement. Un swap plus une police système de repli aux métriques proches règle la question, au prix d’un léger décalage qu’il faut ensuite surveiller côté stabilité visuelle du rendu.

Les single-page applications concentrent à elles seules une bonne part des mauvais diagnostics, et trois pièges s’y superposent. Le squelette de chargement peint un placeholder gris qui devient candidat, puis le contenu réel arrive et repousse la mesure. L’hydratation retarde le rendu final alors que le HTML est parfois déjà là. Et surtout, CrUX ne mesure que la navigation initiale : les navigations douces d’un routeur React ou Next ne produisent aucune nouvelle entrée LCP, donc l’expérience du lecteur qui parcourt cinq pages n’apparaît nulle part dans votre rapport. Un site en SPA peut afficher un LCP flatteur en Search Console et rester pénible à utiliser. Le rendu côté serveur, ou mieux la génération statique, reste la seule réponse structurelle.

Restent les fautes d’exploitation, toujours les mêmes : le bandeau de consentement dont l’overlay devient l’élément le plus grand du viewport, le carrousel d’ouverture qui charge quatre visuels au lieu d’un, le gestionnaire de tags qui injecte huit scripts en tête de document, le TTFB laissé à 1,4 s parce que personne n’a activé de cache page. Dans la Search Console, l’effet est brutal : le rapport groupe les URLs par gabarit et étiquette un groupe entier en médiocre dès qu’une seule métrique l’est. Des milliers d’URLs remontent alors pour un unique modèle mal réglé, ce qui affole les directions et brouille la priorisation.

Réparer un LCP dégradé, dans le bon ordre

Le seul cadre de diagnostic qui tienne, c’est la décomposition du LCP en quatre sous-parties documentée par web.dev : le temps de réponse serveur, le délai avant que le navigateur découvre la ressource, la durée de téléchargement de cette ressource, puis le délai de rendu une fois qu’elle est disponible. Mesurez les quatre avant de toucher quoi que ce soit. La répartition cible que documente web.dev laisse au TTFB et au téléchargement l’essentiel du budget et réduit à presque rien les deux délais. Dans la vraie vie, c’est presque toujours l’un de ces deux délais qui explose, et c’est celui qu’on optimise en dernier.

Ensuite, l’ordre est mécanique. TTFB au-dessus de 800 ms : on règle le cache et le CDN avant de parler d’images. Délai de découverte élevé : la ressource est référencée en CSS ou injectée en JavaScript, remettez-la dans le HTML initial, en <img> avec srcset. Durée de téléchargement élevée : passez en AVIF ou WebP et servez la bonne taille au bon viewport, une image d’ouverture de 1,4 Mo sur mobile n’a aucune excuse en 2026. Délai de rendu élevé : cherchez le CSS bloquant, la police, ou un composant qui attend l’hydratation.

Pour la mise en œuvre côté développeur, cette intervention déroule les arbitrages d’optimisation dans le détail :

Et la vidéo officielle de Google reprend le même sujet par l’autre bout, celui de l’expérience perçue :

Dernier arbitrage, budgétaire, et il est rarement posé honnêtement. Faire passer un LCP de 3,4 s à 2,3 s occupe un développeur front environ une semaine et met 28 jours à se voir dans CrUX. C’est rentable quand le reste tient déjà. Quand le site n’a ni contenu ni liens, cette semaine achète un départage sur des requêtes où vous n’êtes pas en lice : regardez plutôt ce que coûte réellement un article publié chez un éditeur et arbitrez le budget global. Le LCP se corrige une fois puis se surveille, l’autorité se construit sur des mois.