Par le passé, les développeurs Web avaient du mal à mesurer la vitesse de chargement et de visibilité du contenu principal d'une page Web. 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 avions recommandé des métriques de performances telles que le First Meaningful Paint (FMP) et l'Speed Index (IS) (tous deux disponibles dans Lighthouse) pour vous aider à mieux capturer l'expérience de chargement après le chargement initial. Toutefois, ces métriques sont complexes, difficiles à expliquer et souvent erronées. En d'autres termes, 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 existe un moyen plus précis de mesurer le chargement du contenu principal d'une page en vérifiant à quel moment le plus grand élément est affiché.
Qu'est-ce que le LCP ?
Le LCP indique le délai d'affichage du plus grand bloc de texte ou image 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 d'afficher un Largest Contentful Paint de 2,5 secondes au maximum. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, un seuil approprié à mesurer est le 75e centile des chargements de pages, segmenté en fonction des appareils mobiles et des ordinateurs.
Quels sont les éléments pris en compte ?
Comme indiqué actuellement dans la règle Largest Contentful Paint de l'API, les types d'éléments pour le Largest Contentful Paint:
- Éléments
<img>(le temps de présentation de la première image 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> - Des éléments
<video>(le temps de chargement de l'image poster ou le temps de présentation de la première image pour les vidéos est utilisé, selon l'événement qui survient en premier) - Un élément avec une image de fond chargée à l'aide de la fonction
url()(par opposition à un dégradé CSS) - Éléments au niveau du bloc contenant des nœuds de texte ou d'autres éléments de texte intégrés au niveau de l'élément.
Notez que la restriction des éléments à cet ensemble limité était intentionnelle afin de simplifier au début les choses. D'autres éléments (comme la compatibilité complète avec <svg>) pourront être ajoutés ultérieurement, à 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 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 recouvrant toute la fenêtre d'affichage, susceptibles d'être considérés comme un arrière-plan plutôt que comme du 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é 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 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 envoie une PerformanceEntry de type largest-contentful-paint identifiant le plus grand élément Contentful dès que le navigateur a peint le premier cadre. 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 de héros, le navigateur peut se contenter d'afficher le texte au départ. À ce stade, il envoie une entrée largest-contentful-paint dont la propriété element ferait probablement référence à <p> ou <h1>. Plus tard, une fois le chargement de l'image héros terminé, une deuxième entrée largest-contentful-paint est envoyée et sa propriété element fait référence à <img>.
Un élément ne peut être considéré comme le plus grand élément de contenu qu'une fois qu'il a été affiché et qu'il est visible par l'utilisateur. Les images qui n'ont pas encore été chargées ne sont pas considérées comme "affichées". Il en va de même pour les nœuds de texte qui utilisent des polices Web au cours de la période du bloc de polices. Dans ce cas, un élément plus petit peut être signalé comme le plus grand élément contenu, mais dès que l'élément de plus grande taille termine son affichage, un autre PerformanceEntry est créé.
Outre le chargement tardif des images et des polices, une page peut ajouter de nouveaux éléments au DOM à mesure que du nouveau contenu devient disponible. Si l'un de ces nouveaux éléments est plus grand que le précédent, une nouvelle valeur PerformanceEntry est également signalée.
Si l'élément de contenu le plus grand est supprimé de la fenêtre d'affichage, ou même du DOM, il reste l'élément de contenu le plus grand, sauf si un élément de plus grande taille est affiché.
Le navigateur cesse de signaler les nouvelles entrées dès que l'utilisateur interagit avec la page (en appuyant sur l'écran, en faisant défiler l'écran ou en appuyant sur une touche), car cette action modifie souvent ce qui est visible (ce qui est particulièrement vrai pour 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 cela est dû aux restrictions de sécurité qui s'appliquent.
Dans la mesure du possible, il est toujours recommandé de définir l'en-tête Timing-Allow-Origin afin d'améliorer la précision de vos métriques.
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 initiale de l'élément dans la fenêtre d'affichage sont prises en compte.
Cela signifie que les images qui s'affichent initialement hors de l'écran, puis la transition à l'écran, risquent de ne pas être signalées. Cela signifie également que les éléments initialement affichés dans la fenêtre d'affichage, qui sont ensuite déplacés vers le bas, hors de la 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 qui se charge tardivement soit 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 s'est produit avant le chargement complet de la page.
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 la 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 de l'une des images ou du logo. Étant donné que toutes les images individuelles sont plus petites que ce paragraphe, il reste le plus grand élément tout au long du processus de chargement.
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
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 objet 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 LCP actuel. En général, la valeur startTime de la dernière entrée émise correspond à la valeur LCP, mais 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 enverra des 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 continuera à envoyer les 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 au premier plan pendant tout le temps). - 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 perçoivent comme des visites de page distinctes. - L'API ne prend pas en compte les éléments inclus dans les cadres iFrame, mais la métrique tient compte de leur intégration dans l'expérience utilisateur de la page. Dans les pages avec un LCP dans un iFrame (une image poster sur une vidéo intégrée, par exemple), cela constitue une différence entre CrUX et RUM. Pour mesurer correctement le LCP, vous devez en tenir compte. 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 au début de la navigation. Toutefois, pour les pages prérendues, le LCP doit être mesuré à partir de
activationStart, car il correspond au temps LCP constaté par l'utilisateur.
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 des cadres iFrame n'est pas abordé):
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 la façon de mesurer le LCP en JavaScript.
Et si le plus grand élément n'est pas le plus important ?
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. Vous pouvez pour cela utiliser 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écouverts 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 elles peuvent apparaître sous forme d'améliorations ou de 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 concernant ces métriques, vous pouvez les envoyer dans le groupe Google "web-vitals-feedback".