La métrique LCP (Largest Contentful Paint) est une métrique Core Web Vitals stable qui permet de mesurer la vitesse de chargement perçue. Elle marque le moment dans la chronologie de chargement de la page où le contenu principal de la page est susceptible de s'être chargé. Un LCP rapide permet de rassurer l'utilisateur sur l'utilité de la page.
Historiquement, mesurer la vitesse de chargement du contenu principal d'une page Web et sa visibilité auprès des utilisateurs représentait un défi pour les développeurs Web. Les métriques plus anciennes telles que load (chargement) ou DOMContentLoaded ne fonctionnent pas bien, car elles ne correspondent pas nécessairement à ce que l'utilisateur voit à l'écran. De plus, les nouvelles métriques de performances axées sur l'utilisateur, telles que First Contentful Paint (FCP), ne capturent 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.
Auparavant, nous recommandions des métriques de performances telles que First Meaningful Paint (FMP) et Speed Index (SI) (toutes deux disponibles dans Lighthouse) pour vous aider à mieux visualiser l'expérience de chargement après le chargement initial. Toutefois, ces métriques sont complexes, difficiles à expliquer et souvent erronées, ce qui signifie qu'elles ne permettent toujours pas d'identifier le moment où le contenu principal de la page est chargé.
D'après les discussions menées au sein du W3C Web Performance Working Group et les recherches menées par Google, nous avons découvert qu'un moyen plus précis de mesurer le chargement du contenu principal d'une page consiste à vérifier à quel moment l'élément le plus volumineux est affiché.
Qu'est-ce que le LCP ?
Le LCP indique le délai d'affichage du plus grand bloc d'image ou 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 bonne expérience utilisateur, les sites doivent s'efforcer d'avoir un LCP de 2,5 secondes ou moins. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile des chargements de page, segmenté entre les appareils mobiles et les ordinateurs, constitue un bon seuil à mesurer.
Quels sont les éléments pris en compte ?
Comme spécifié dans l'API Largest Contentful Paint, les types d'éléments pris en compte pour le Largest Contentful Paint sont les suivants:
- Éléments
<img>(le délai de présentation du premier frame est utilisé pour les contenus animés, tels que les GIF ou les fichiers PNG animés) - Éléments
<image>dans un élément<svg> <video>éléments (le temps de chargement de l'image poster ou le temps de présentation de la première image des vidéos est utilisé, selon la valeur qui survient en premier)- Élément avec une image de fond chargée à l'aide de la fonction
url()(par opposition à un dégradé CSS). - Les éléments au niveau du bloc contenant des nœuds de texte ou d'autres éléments enfants d'éléments textuels intégrés au niveau du bloc.
Limiter les éléments à cet ensemble limité était intentionnel pour réduire la complexité.
Des éléments supplémentaires (comme la compatibilité complète avec <svg>) pourront être ajoutés à l'avenir au fur et à mesure que d'autres recherches seront menées.
En plus de ne tenir compte que de certains éléments, les mesures du LCP utilisent des méthodes heuristiques pour exclure certains éléments que les utilisateurs sont susceptibles de considérer comme "non contenus". Pour les navigateurs Chromium, par exemple:
- Éléments ayant une opacité de 0, ce qui les rend invisibles pour l'utilisateur
- Éléments recouvrant l'ensemble de la fenêtre d'affichage, susceptibles d'être des éléments d'arrière-plan
- Images d'espaces réservés ou d'autres images à entropie faible qui ne reflètent probablement pas le contenu réel de la page
Les navigateurs vont probablement continuer à améliorer ces méthodes heuristiques pour s'assurer que nous répondons aux attentes des utilisateurs concernant l'élément contentful le plus important.
Ces méthodes heuristiques "contentes" diffèrent de celles utilisées par le FCP, qui peut prendre en compte certains de ces éléments, tels que les images de remplissage ou les images de fenêtre d'affichage complète, même s'ils ne sont pas éligibles au LCP. Même s'ils utilisent le terme "contentful" dans leur nom, l'objectif de ces métriques est différent. Le FCP mesure le moment où n'importe quel contenu est affiché à l'écran, tandis que le LCP mesure le moment où le contenu principal est affiché.
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 à la taille 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 des éléments est rogné ou présente un overflow non visible, ces parties ne sont pas prises en compte dans la taille de l'élément.
Pour les éléments d'image redimensionnés à partir de leur taille intrinsèque, la taille signalée est soit la taille visible, soit la taille intrinsèque, selon celle qui est la plus petite.
Pour les éléments textuels, le LCP ne prend en compte que le 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 ni des bordures appliquées à l'aide de code CSS.
Quand le LCP est-il indiqué ?
Les pages Web se chargent souvent par étapes. Par conséquent, l'élément le plus grand de la page peut changer lors du chargement.
Pour gérer ce potentiel de modification, le navigateur envoie un PerformanceEntry de type largest-contentful-paint identifiant le plus grand élément contenu dès que le navigateur a peint le premier frame. Après le rendu des frames suivants, il envoie un autre PerformanceEntry chaque fois que l'élément le plus important change.
Par exemple, sur une page contenant du texte et une image de héros, le navigateur peut n'afficher que le texte au départ, puis il enverra une entrée largest-contentful-paint dont la propriété element fait référence à une <p> ou à un <h1>. Une fois le chargement de l'image héros terminé, une deuxième entrée largest-contentful-paint est envoyée, avec une propriété element qui référence <img>.
Un élément ne peut être considéré comme le plus grand élément contenu qu'une fois affiché et visible par l'utilisateur. Les images qui n'ont pas encore été chargées ne sont pas considérées comme "rendues". Il en va de même pour les nœuds de texte qui utilisent des polices Web pendant la période de blocage de police.
Dans ce cas, un élément plus petit peut être signalé comme étant le plus grand élément contenu, mais dès que l'affichage de l'élément plus grand est terminé, une autre PerformanceEntry est créée.
Outre le chargement tardif des images et des polices, 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 contenu précédent, une PerformanceEntry est créée.
Si l'élément contenu le plus grand est supprimé de la fenêtre d'affichage, voire du DOM, il reste le plus grand élément contenu, à moins qu'un élément plus grand ne soit affiché.
Le navigateur cesse de signaler les nouvelles entrées dès que l'utilisateur interagit avec la page (par le biais d'un appui, d'un défilement ou d'une pression sur une touche), car cette action modifie souvent ce qui est visible pour l'utilisateur (en particulier lorsqu'il la fait défiler).
À des fins d'analyse, ne signalez que le PerformanceEntry envoyé le plus récemment à votre service d'analyse.
Comparaison entre le temps de chargement et le délai d'affichage
Pour des raisons de sécurité, l'horodatage de rendu des images n'est pas exposé pour les images multi-origines dépourvues d'en-tête Timing-Allow-Origin. À la place, seul leur temps de chargement, que d'autres API exposent, est disponible.
Cela peut entraîner une situation en apparence impossible, dans laquelle le LCP est signalé par les API Web comme étant antérieur à FCP. Cela est uniquement dû à cette restriction de sécurité, et cela ne représente pas la situation réelle.
Dans la mesure du possible, nous vous recommandons de toujours définir l'en-tête Timing-Allow-Origin pour améliorer la précision de vos métriques.
Comment les changements de mise en page et de taille des éléments sont-ils gérés ?
Pour limiter l'impact sur les performances du calcul et de l'envoi des nouvelles entrées de performances, les modifications de la taille ou de la position d'un élément ne génèrent pas de nouveaux candidats au 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 initialement affichées hors écran, puis transférées à l'écran peuvent ne pas être signalées. Cela signifie également que les éléments initialement affichés dans la fenêtre d'affichage et qui sont ensuite retirés de la vue indiquent toujours leur taille initiale dans la fenêtre d'affichage.
Exemples
Voici quelques exemples d'apparition de la métrique "Largest Contentful Paint" sur certains sites Web populaires:
Dans ces deux chronologies, l'élément le plus grand (en vert) change à mesure que le contenu se charge. Dans le premier exemple, du 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 plus grand élément de contenu précédent est supprimé de la fenêtre d'affichage.
Bien que le contenu à chargement tardif 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 que le LCP se produit avant le chargement complet de la page.
Dans le premier exemple, le logo Instagram se charge relativement tôt et reste l'élément le plus grand, même si d'autres contenus sont ajoutés. Dans l'exemple de page de résultats de recherche Google, le plus grand élément est un paragraphe de texte qui s'affiche avant la fin du chargement des images ou du logo. Comme chaque image individuelle est plus petite que ce paragraphe, elle reste l'élément le plus grand tout au long du processus de chargement.
Mesurer le LCP
Le LCP peut être mesuré en atelier ou sur le terrain. Il est disponible dans les outils suivants:
Outils de terrain
- Rapport d'expérience utilisateur Chrome
- PageSpeed Insights
- Search Console (rapport Core Web Vitals)
- Bibliothèque JavaScript
web-vitals
Outils de l'atelier
Mesurer le LCP en JavaScript
Pour mesurer le LCP en JavaScript, utilisez 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 précédent, chaque entrée largest-contentful-paint enregistrée représente le LCP actuel. En général, la valeur startTime de la dernière entrée émise correspond à la valeur du LCP. Cependant, toutes les entrées largest-contentful-paint ne sont pas valides pour mesurer le LCP.
La section suivante répertorie les différences entre les rapports générés par l'API et le mode de calcul de la métrique.
Différences entre la métrique et l'API
- L'API distribue les entrées
largest-contentful-paintpour 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-paintaprès la mise en arrière-plan d'une page, 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 affichée au premier plan pendant toute la durée de l'opération. - L'API ne signale pas les entrées
largest-contentful-paintlorsque la page est restaurée à partir du cache amélioré, mais le LCP doit être mesuré dans ces cas, car les utilisateurs les voient comme des visites de page distinctes. - L'API ne prend pas en compte les éléments des cadres iFrame, mais la métrique le prend en compte, car ils font partie de l'expérience utilisateur sur la page. Sur les pages qui comportent un LCP dans un iFrame (par exemple, une image poster sur une vidéo intégrée), cela se manifeste une différence entre CrUX et RUM.
Pour mesurer correctement le LCP, vous devez inclure des cadres iFrame. Les sous-frames peuvent utiliser l'API pour signaler leurs entrées
largest-contentful-paintau frame parent à des fins d'agrégation. - L'API mesure le LCP dès le début de la navigation. Pour les pages prérendues, mesurez plutôt le LCP à partir de
activationStart, car cela correspond à la durée LCP telle qu'elle est perçue par l'utilisateur.
Au lieu de mémoriser toutes ces différences subtiles, nous recommandons aux développeurs d'utiliser la bibliothèque JavaScript web-vitals pour mesurer le LCP, qui gère la plupart de ces différences pour vous. Notez qu'il n'aborde pas le problème des cadres iFrame.
import {onLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
onLCP(console.log);
Reportez-vous au code source pour onLCP() pour obtenir un exemple complet de mesure du LCP en JavaScript.
Et si l'élément le plus grand n'était pas le plus important ?
Dans certains cas, l'élément (ou les éléments) le plus important de la page n'est pas le même que l'élément le plus grand. Les développeurs peuvent préférer mesurer les délais d'affichage de ces autres éléments. Cela est possible à l'aide de 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 guider tout au long du processus d'identification des temps LCP sur le terrain et d'utilisation des données de laboratoire pour les examiner en détail 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 se présenter comme des améliorations ou des régressions dans vos rapports et tableaux de bord internes.
Pour vous aider à gérer cela, toutes les modifications apportées à l'implémentation ou à la définition de ces métriques sont présentées dans ce journal des modifications.
Si vous avez des commentaires sur ces métriques, envoyez-les dans le groupe Google web-vitals-feedback.