Jusqu'à présent, mesurer la vitesse de chargement du contenu principal d'une page Web et de le rendre visible pour les utilisateurs représentait un défi pour les développeurs Web. Les anciennes métriques, comme 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, comme First Contentful Paint (FCP), ne tiennent compte que du 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. En d'autres termes, elles ne permettent toujours pas d'identifier le moment où le contenu principal de la page est chargé.
En nous appuyant sur des discussions menées au sein du W3C Web Performance Working Group et sur des recherches menées par Google, nous avons découvert qu'un moyen plus précis de mesurer le moment où le contenu principal d'une page est chargé consiste à déterminer quand 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 expérience utilisateur de qualité, les sites doivent s'efforcer de ne pas dépasser 2,5 secondes pour le Largest Contentful Paint. Pour vous assurer d'atteindre cet objectif pour la plupart de vos utilisateurs, le 75e centile des chargements de pages est un bon seuil à mesurer, segmenté selon les appareils mobiles et les ordinateurs.
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 cette fonctionnalité 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) - É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
Notez que la restriction des éléments à cet ensemble limité était intentionnelle afin de simplifier les choses au début. Des éléments supplémentaires (comme la compatibilité complète avec <svg>) pourront être ajoutés à l'avenir au fur et à mesure des recherches.
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:
- Éléments ayant une opacité de 0 et qui sont invisibles pour l'utilisateur
- Éléments recouvrant l'ensemble de la fenêtre d'affichage, probablement considérés comme un arrière-plan plutôt que comme du contenu
- 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 que nous puissions répondre aux attentes des utilisateurs concernant l'élément content le plus important.
Ces méthodes heuristiques "contentful" peuvent différer de celles utilisées par le système First Contentful Paint (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 et le LCP lorsque le contenu principal est peint, afin que le LCP soit 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 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 image redimensionnés à partir de leur taille intrinsèque, la taille indiquée correspond 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 via le code CSS.
Quand le LCP est-il indiqué ?
Les pages Web se chargent souvent par étapes. Par conséquent, il est possible que l'élément le plus grand de la page change.
Pour gérer ce potentiel de changement, le navigateur envoie 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. Toutefois, 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 héros, le navigateur peut simplement afficher le texte. Le navigateur envoie alors 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 fera 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 "affichées". 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. Toutefois, dès que l'affichage de cet é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 de contenu le plus ancien, un nouvel élément PerformanceEntry sera également signalé.
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 soit affiché.
Le navigateur cesse de signaler les nouvelles entrées dès que l'utilisateur interagit avec la page (en appuyant, en la faisant défiler ou en appuyant sur une touche), car l'interaction utilisateur modifie souvent ce qui est visible pour l'utilisateur (ce qui est particulièrement vrai avec le défilement).
À des fins d'analyse, vous ne devez signaler que les PerformanceEntry qui ont été envoyés 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 de l'en-tête Timing-Allow-Origin. Au lieu de cela, seul leur temps de chargement est exposé (puisqu'ils sont déjà exposés par de nombreuses autres API Web).
Cela peut entraîner une situation en apparence impossible, dans laquelle le LCP est signalé par les API Web comme étant antérieur au FCP. Ce n'est pas le cas, mais cela n'est le cas qu'en raison de cette restriction de sécurité.
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 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 apportées à la taille ou à 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 qui sont d'abord 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, puis déplacés vers le bas pour qu'ils ne soient plus visibles, 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 les deux chronologies ci-dessus, l'élément le plus grand change au fur et à mesure du chargement du contenu. 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 contenu qui était auparavant le plus grand 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 le LCP qui se produit avant le chargement complet de la page.
Dans le premier exemple, le logo Instagram est chargé relativement tôt et reste l'élément le plus grand, 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 la fin du chargement des images ou des logos. Comme toutes les images individuelles sont plus petites que ce paragraphe, elle reste l'élément le plus grand tout au long du processus de chargement.
Mesurer le LCP
Vous pouvez mesurer le LCP dans l'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, 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 LCP actuel. En général, la valeur startTime de la dernière entrée émise est 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 indique 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 continue de distribuer 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 toute la durée). - 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 pages distinctes. - L'API ne tient pas compte des éléments dans les cadres iFrame, mais la métrique les 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 les prendre en 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 dès le début de la navigation, mais pour les pages prérendues, le LCP doit être mesuré à partir de
activationStart, car il correspond à la durée LCP telle qu'elle est perçue 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 pour vous (dans la mesure du possible, le problème des cadres iFrame n'est pas traité):
import {onLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
onLCP(console.log);
Reportez-vous au code source de 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 le plus grand. Les développeurs seront peut-être plus enclins à mesurer les délais d'affichage de ces autres éléments à la place. 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
Des bugs sont parfois découverts dans les API utilisées pour mesurer les métriques, et parfois dans les définitions des métriques elles-mêmes. Des modifications doivent donc 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, 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 faire dans le groupe Google web-vitals-feedback.