Largest Contentful Paint (LCP)

Philip Walton

Barry Pollard

Historiquement, il a été difficile pour les développeurs Web de mesurer la rapidité avec laquelle le contenu principal d'une page Web se charge et est visible par les utilisateurs. Les anciennes métriques, telles que load ou DOMContentLoaded, ne sont pas efficaces, car elles ne correspondent pas nécessairement à ce que l'utilisateur voit sur son écran. De plus, les nouvelles métriques de performances axées sur l'utilisateur, telles que First Contentful Paint (FCP), ne concernent que le tout début de l'expérience de chargement. Si une page affiche un écran de démarrage ou un indicateur de chargement, ce moment n'est pas très pertinent pour l'utilisateur.

Par le passé, nous recommandions des métriques de performances telles que First Meaningful Paint (FMP) (Première peinture significative) et Speed Index (SI) (Indice de vitesse) (les deux disponibles dans Lighthouse) pour mieux capturer l'expérience de chargement après la peinture initiale. Toutefois, ces métriques sont complexes, difficiles à expliquer et souvent incorrectes, ce qui signifie qu'elles n'identifient toujours pas quand le contenu principal de la page a été chargé.

D'après les discussions du W3C Web Performance Working Group et les recherches menées par Google, nous avons constaté qu'il était plus précis de mesurer le moment où le contenu principal d'une page est chargé en examinant le moment où l'élément le plus volumineux est affiché.

Qu'est-ce que le LCP ?

Le LCP indique le délai d'affichage de la plus grande image, vidéo ou bloc de texte visible dans la fenêtre d'affichage, par rapport au moment où l'utilisateur a accédé à la page pour la première fois.

Qu'est-ce qu'un bon score LCP ?

Pour offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de 2,5 secondes ou moins pour la valeur Largest Contentful Paint. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile de chargements de pages, segmenté en fonction des appareils mobiles et des ordinateurs, constitue un bon seuil à mesurer.

Quels sont les éléments pris en compte ?

Tel que spécifié dans la règle Largest Contentful Paint de l'API, les types d'éléments pour le Largest Contentful Paint:

• Éléments <img> (la durée de présentation du premier frame est utilisée pour les contenus animés tels que les GIF ou les PNG animés)
• Éléments <image> dans un élément <svg>
• éléments <video> (le temps de chargement de l'image poster ou le temps de présentation du premier frame pour les vidéos est utilisé, le plus tôt possible)
• Un élément avec une image de fond chargée à l'aide de la fonction url() (par opposition à un dégradé CSS)
• Éléments de niveau bloc contenant des nœuds de texte ou d'autres éléments enfants de texte au niveau de l'alignement en ligne.

Notez que nous avons volontairement limité les éléments à cet ensemble afin de simplifier les choses au début. D'autres éléments (comme la prise en charge complète de <svg>) pourront être ajoutés à l'avenir à mesure que des recherches supplémentaires seront menées.

En plus de ne prendre en compte que certains éléments, les mesures du LCP utilisent des heuristiques pour exclure certains éléments que les utilisateurs sont susceptibles de considérer comme "sans contenu". Pour les navigateurs basés sur Chromium, il s'agit des éléments suivants:

• Éléments avec une opacité de 0, qui sont invisibles pour l'utilisateur
• Éléments qui couvrent l'intégralité de la fenêtre d'affichage et qui sont probablement considérés comme un arrière-plan plutôt que comme un contenu
• Images d'espace réservé ou autres images à faible entropie, qui ne reflètent probablement pas le véritable contenu de la page

Il est probable que les navigateurs continuent d'améliorer ces heuristiques pour s'assurer que nous répondons aux attentes des utilisateurs concernant l'élément le plus content.

Ces contenus "contents" Les méthodes heuristiques peuvent différer de celles utilisées par le FCP (First Contentful Paint), qui peut prendre en compte certains de ces éléments, tels que des images d'espace réservé ou des images de la fenêtre d'affichage complète, même s'ils ne sont pas éligibles au LCP. Même si les termes "contentful" dans leur nom, l'objectif de ces métriques est différent. Le FCP mesure l'affichage de n'importe quel contenu à l'écran, tandis que le LCP est appliqué lorsque le contenu principal est affiché. Le LCP est donc conçu pour être plus sélectif.

Comment la taille d’un élément est-elle déterminée ?

La taille de l'élément indiquée pour le LCP correspond généralement à celle visible par l'utilisateur dans la fenêtre d'affichage. Si l'élément s'étend en dehors de la fenêtre d'affichage, ou si l'un d'entre eux est rogné ou présente un dépassement non visible, ces parties ne sont pas comptabilisées dans la taille de l'élément.

Pour les éléments d'image qui ont été redimensionnés à partir de leur taille intrinsèque, la taille signalée est soit la taille visible, soit la taille intrinsèque (la plus petite).

Pour les éléments de texte, le LCP ne tient compte que du plus petit rectangle pouvant contenir tous les nœuds de texte.

Pour tous les éléments, le LCP ne tient pas compte des marges, des marges intérieures ou des bordures appliquées à l'aide de CSS.

Quand le LCP est-il consigné ?

Les pages Web se chargent souvent par étapes. Par conséquent, il est possible que le plus grand élément de la page change.

Pour gérer ce potentiel de modification, le navigateur distribue un PerformanceEntry de type largest-contentful-paint identifiant le plus grand élément de contenu dès que le navigateur a peint le premier frame. Cependant, après l'affichage des frames suivants, un autre PerformanceEntry est envoyé chaque fois que l'élément de contenu de plus grande taille change.

Par exemple, sur une page contenant du texte et une image héros, le navigateur peut n'afficher initialement que le texte. À ce stade, il distribue une entrée largest-contentful-paint dont la propriété element fait probablement référence à un <p> ou à un <h1>. Plus tard, une fois l'image principale chargée, une deuxième entrée largest-contentful-paint sera envoyée et sa propriété element référencera <img>.

Un élément ne peut être considéré comme le plus grand élément avec contenu qu'après avoir été affiché et être visible par l'utilisateur. Les images qui n'ont pas encore été chargées ne sont pas considérées comme "rendues". Les nœuds de texte qui utilisent des polices Web ne sont pas non plus concernés pendant la période de blocage des polices. Dans ce cas, un élément plus petit peut être signalé comme étant le plus grand élément avec contenu, mais dès que l'élément plus grand a terminé le rendu, un autre PerformanceEntry est créé.

En plus des images et des polices chargées tardivement, une page peut ajouter de nouveaux éléments au DOM à mesure que de nouveaux contenus deviennent disponibles. Si l'un de ces nouveaux éléments est plus grand que le plus grand élément avec contenu précédent, un nouvel élément PerformanceEntry est également signalé.

Si le plus grand élément avec contenu est supprimé de la fenêtre d'affichage ou même du DOM, il reste le plus grand élément avec contenu, sauf si un élément plus grand est affiché.

Le navigateur cesse de signaler de nouvelles entrées dès que l'utilisateur interagit avec la page (en appuyant dessus, en faisant défiler la page ou en appuyant sur une touche), car l'interaction de l'utilisateur modifie souvent ce qui est visible (ce qui est particulièrement vrai avec le défilement).

À des fins d'analyse, vous ne devez signaler que les PerformanceEntry les plus récemment envoyés à votre service d'analyse.

Temps de chargement et temps d'affichage

Pour des raisons de sécurité, l'horodatage de rendu des images n'est pas exposé pour les images multi-origines qui n'incluent pas l'en-tête Timing-Allow-Origin. En effet, seul leur temps de chargement est exposé (étant donné qu'il est déjà exposé dans de nombreuses autres API Web).

Cela peut entraîner une situation apparemment impossible où le LCP est signalé par les API Web comme étant antérieur au FCP. Ce n'est pas le cas, mais c'est seulement en raison de cette restriction de sécurité.

Dans la mesure du possible, nous vous recommandons toujours de définir l'en-tête Timing-Allow-Origin afin que vos métriques soient plus précises.

Comment les modifications de mise en page et de taille des éléments sont-elles gérées ?

Pour limiter l'impact sur les performances du calcul et de l'envoi des nouvelles entrées de performances, les modifications apportées à la taille ou à la position d'un élément ne génèrent pas de nouveaux candidats LCP. Seules la taille et la position initiales de l'élément dans la fenêtre d'affichage sont prises en compte.

Cela signifie que les images qui sont initialement affichées en dehors de l'écran, puis qui passent à l'écran, ne sont pas nécessairement enregistrées. Cela signifie également que les éléments initialement affichés dans la fenêtre d'affichage qui sont ensuite repoussés vers le bas, hors de vue, indiquent toujours leur taille initiale dans la fenêtre d'affichage.

Exemples

Voici quelques exemples de situations où le Largest Contentful Paint apparaît sur quelques sites Web populaires:

Dans les deux chronologies ci-dessus, l'élément le plus important change au fur et à mesure que le contenu se charge. Dans le premier exemple, un nouveau contenu est ajouté au DOM, ce qui modifie l'élément le plus grand. Dans le deuxième exemple, la mise en page change et le contenu qui était auparavant le plus grand est supprimé de la fenêtre d'affichage.

Bien que le contenu chargé tardivement soit souvent plus volumineux que le contenu déjà présent sur la page, ce n'est pas nécessairement le cas. Les deux exemples suivants montrent le LCP qui se produit avant le chargement complet de la page.

<ph type="x-smartling-placeholder">

<ph type="x-smartling-placeholder">

Dans le premier exemple, le logo Instagram est chargé assez tôt et il reste le plus grand élément, même si d'autres contenus sont progressivement affichés. Dans l'exemple de page de résultats de recherche Google, l'élément le plus grand est un paragraphe de texte qui s'affiche avant que les images ou le logo ne soient chargés. Étant donné que toutes les images individuelles sont plus petites que ce paragraphe, il reste l'élément le plus grand tout au long du processus de chargement.

Comment mesurer le LCP

Le LCP peut être mesuré en laboratoire ou sur le terrain, et il est disponible avec les outils suivants:

Outils de terrain

• Rapport sur l'expérience utilisateur Chrome
• PageSpeed Insights
• Search Console (rapport Core Web Vitals)
• Bibliothèque JavaScript web-vitals

Outils de l'atelier

• Outils pour les développeurs Chrome
• Phare
• PageSpeed Insights
• WebPageTest

Mesurer le LCP en JavaScript

Pour mesurer le LCP en JavaScript, vous pouvez utiliser l'API Largest Contentful Paint. L'exemple suivant montre comment créer un PerformanceObserver qui écoute les entrées largest-contentful-paint et les consigne dans la console.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Dans l'exemple ci-dessus, chaque entrée largest-contentful-paint enregistrée représente le candidat au LCP actuel. En général, la valeur startTime de la dernière entrée émise correspond à la valeur LCP. Toutefois, ce n'est pas toujours le cas. Les entrées largest-contentful-paint ne sont pas toutes valides pour mesurer le LCP.

La section suivante répertorie les différences entre les rapports de l'API et le mode de calcul de la métrique.

Différences entre la métrique et l'API

• L'API distribue des entrées largest-contentful-paint pour les pages chargées dans un onglet en arrière-plan, mais ces pages doivent être ignorées lors du calcul du LCP.
• L'API continue de distribuer des entrées largest-contentful-paint après qu'une page a été mise en arrière-plan, mais ces entrées doivent être ignorées lors du calcul du LCP (les éléments ne peuvent être pris en compte que si la page était au premier plan tout le temps).
• L'API ne signale pas d'entrées largest-contentful-paint lorsque la page est restaurée à partir du cache avant/arrière, mais le LCP doit être mesuré dans ce cas, car les utilisateurs le perçoivent comme des visites de pages distinctes.
• L'API ne prend pas en compte les éléments contenus dans les cadres iFrame, mais la métrique s'en charge, car ils font partie de l'expérience utilisateur de la page. Dans les pages avec un LCP dans un iFrame (par exemple, une image poster sur une vidéo intégrée), cela constituera une différence entre CrUX et RUM. Pour mesurer correctement le LCP, vous devez en tenir compte. Les sous-cadres peuvent utiliser l'API pour signaler leurs entrées largest-contentful-paint au frame parent à des fins d'agrégation.
• L'API mesure le LCP à partir du début de la navigation, mais pour les pages prérendues, le LCP doit être mesuré à partir de activationStart, car cela correspond au temps LCP tel que l'utilisateur l'a vécu.

Plutôt que de mémoriser toutes ces différences subtiles, les développeurs peuvent utiliser la bibliothèque JavaScript web-vitals pour mesurer le LCP, qui gère ces différences à votre place (dans la mesure du possible, notez que le problème d'iFrame n'est pas couvert) :

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

Consultez le code source de onLCP() pour obtenir un exemple complet de mesure du LCP en JavaScript.

Que se passe-t-il si l'élément le plus important n'est pas le plus grand ?

Dans certains cas, le ou les éléments les plus importants de la page ne correspondent pas au plus grand. Les développeurs peuvent donc préférer mesurer les délais d'affichage de ces autres éléments. Cela est possible en utilisant l'API Element Timing, comme décrit dans l'article sur les métriques personnalisées.

Améliorer le LCP

Un guide complet sur l'optimisation du LCP est disponible pour vous aider à identifier les délais LCP sur le terrain et à utiliser des données de laboratoire pour les analyser et les optimiser.

Ressources supplémentaires

• Leçons tirées de la surveillance des performances dans Chrome par Annie Sullivan, sur performance.now() (2019)

Journal des modifications

Il arrive que des bugs soient détectés dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Par conséquent, des modifications doivent parfois être apportées, et ces modifications peuvent apparaître comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.

Pour vous aider, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques seront affichées dans ce journal des modifications.

Si vous avez des commentaires sur ces métriques, vous pouvez les envoyer dans le groupe Google web-vitals-feedback.