Qu'est-ce qui compte comme élément LCP sur une page typique ?

L'élément visible qui affiche le plus de pixels dans le viewport - généralement une image d'en-tête, une grande image d'arrière-plan, ou un grand bloc de texte de titre. Les nœuds de texte enveloppés dans le même bloc sont traités comme un seul élément pour cette mesure.

Le LCP est-il mesuré sur mobile, sur ordinateur, ou les deux ?

Les deux, et ils sont souvent en désaccord. Le Website Audit de Scanverra exécute une passe Lighthouse complète sur un profil ordinateur puis à nouveau sur un viewport mobile de 375 px, car une page qui précharge son image d'en-tête peut tout de même être lente sur mobile si cette même image n'est pas servie dans une taille adaptée au mobile.

Le préchargement aide-t-il toujours le LCP ?

Seulement pour la ressource LCP réelle. Précharger des ressources sans rapport rivalise pour la même bande passante précoce et peut aggraver le LCP - préchargez l'image ou la police spécifique que le navigateur découvrirait autrement tardivement, pas tout ce qui se trouve au-dessus de la ligne de flottaison.

Pourquoi mon LCP s'est-il dégradé après avoir ajouté un CDN ?

Un CDN n'aide qu'une fois que les ressources sont réellement mises en cache sur un nœud edge proche du visiteur - la première requête après un déploiement ou une purge de cache est un échec de cache à froid. Si vous testez juste après un déploiement, relancez le test une seconde fois avant de conclure que le CDN ne fonctionne pas.

Comment corriger le Largest Contentful Paint (LCP)

Pourquoi votre LCP est lent

Le LCP est une course entre la requête du navigateur pour votre page et la fin du rendu de ce plus grand élément. Presque tous les LCP lents remontent à l'un de ces quatre obstacles :

Un Time to First Byte lent. Si le serveur met 2 secondes juste pour répondre, le LCP ne peut pas démarrer son chronomètre plus tôt que cela - tout ce qui suit hérite du retard.
Une image d'en-tête non optimisée. Un PNG de 4 Mo servi à la taille d'affichage plutôt que dans un format compressé et correctement dimensionné est la cause la plus fréquente que nous observons.
Du CSS ou JS bloquant le rendu dans le <head>. Le navigateur ne peut rien afficher, y compris l'élément LCP, tant qu'il n'a pas terminé de télécharger et d'analyser les ressources bloquantes.
Une découverte tardive de la ressource. Si l'image LCP n'est référencée qu'au fond d'un background-image CSS ou chargée par JavaScript après l'hydratation, le navigateur ne sait même pas qu'il doit commencer à la récupérer avant bien plus tard qu'il ne le pourrait.

Comment identifier votre élément LCP

Deviner quel élément est votre LCP n'est pas fiable - cela change selon la taille du viewport et le contenu. Le Website Audit de Scanverra exécute une véritable passe Lighthouse à la fois sur un profil ordinateur et sur un viewport mobile de 375 px, et rapporte la valeur et le timing du LCP directement à partir de cette exécution, pas une estimation - vous observez donc la même métrique que celle que les données de terrain de Google finissent par refléter, pas un proxy de celle-ci.

Dans Chrome DevTools, vous pouvez aussi ouvrir le panneau Performance, enregistrer un chargement de page, et repérer le marqueur « LCP » dans la piste de timing - il met en surbrillance l'élément exact dans la page rendue lorsque vous le survolez.

Comment le corriger

1. Préchargez la ressource LCP réelle

Si le navigateur ne peut découvrir votre image d'en-tête qu'après avoir analysé le CSS ou exécuté du JS, informez-le plutôt de l'image dès le départ :

Précharger l'image d'en-tête dans l'en-tête du documenttypescript

1export default function RootLayout() {
2  return (
3    <html lang="en">
4      <head>
5        <link
6          rel="preload"
7          as="image"
8          href="/hero.webp"
9          fetchPriority="high"
10        />
11      </head>
12      <body>{/* ... */}</body>
13    </html>
14  );
15}

2. Marquez l'image LCP comme prioritaire

Si vous affichez l'image d'en-tête via une balise image au niveau composant, marquez-la comme ressource prioritaire afin qu'elle ne soit pas chargée en différé et qu'elle rivalise en premier pour la bande passante :

Chargez l'image d'en-tête en priorité, sans la charger en différétypescript

1<img
2  src="/hero.webp"
3  alt="Product dashboard overview"
4  width={1200}
5  height={630}
6  fetchPriority="high"
7  loading="eager"
8/>

3. Compressez et dimensionnez correctement l'image elle-même

Servez de l'AVIF ou du WebP plutôt que du PNG/JPEG là où le navigateur le prend en charge, et n'envoyez jamais une image plus grande que la plus grande taille à laquelle elle sera réellement affichée - une image source de 3000 px de large réduite avec du CSS coûte toujours le téléchargement complet.

4. Réglez d'abord le TTFB

Précharger une image lente à charger ne corrige pas un serveur lent. Si le TTFB représente une part importante de votre budget LCP, corrigez-le d'abord - voir le guide TTFB ci-dessous - car toute autre optimisation LCP est plafonnée par le moment où le navigateur peut même commencer.

5. Supprimez les ressources bloquant le rendu du chemin critique

Différez ou chargez en asynchrone le JavaScript non critique, intégrez en ligne la petite quantité de CSS nécessaire pour le contenu au-dessus de la ligne de flottaison, et chargez le reste de votre feuille de style sans bloquer le premier affichage.

Comment Scanverra détecte les problèmes de LCP

Les contrôles de performance de Scanverra exécutent un véritable audit Lighthouse sur votre URL en direct, à la fois sur ordinateur et sur un viewport mobile de 375 px, et rapportent le timing LCP réel de cette exécution aux côtés des autres Core Web Vitals - ce n'est ni une estimation synthétique ni un chiffre tiers mis en cache.