Découvrez pourquoi les outils qui surveillent les métriques Core Web Vitals peuvent afficher des chiffres différents et comment interpréter ces différences.
Google propose un certain nombre d'outils pour aider les propriétaires de sites à surveiller leurs scores Core Web Vitals. Ces outils se répartissent en deux grandes catégories:
- Outils qui génèrent des données de laboratoire, c'est-à-dire des données collectées dans un environnement contrôlé avec des paramètres d'appareil et de réseau prédéfinis.
- Outils qui fournissent des données de champ, c'est-à-dire des données collectées auprès des utilisateurs réels qui consultent votre site.
Le problème est que les données signalées par les outils de laboratoire peuvent parfois être très différentes de celles signalées par les outils sur le terrain. Vos données de laboratoire peuvent indiquer que votre site fonctionne très bien, mais vos données sur le terrain suggèrent qu'il doit être amélioré. Il est également possible que vos données sur le terrain indiquent que toutes vos pages sont bonnes, mais que vos données de laboratoire indiquent un score très faible.
L'exemple concret suivant d'un rapport PageSpeed Insights de web.dev montre que, dans certains cas, les données de laboratoire et sur le terrain peuvent être différentes pour toutes les métriques Core Web Vitals:
Les différences entre les outils sont une source de confusion compréhensible pour les développeurs. Cet article explique les principales raisons de ces différences (avec des exemples spécifiques pour chacune des métriques Core Web Vitals) et indique ce que vous devez faire lorsque vous constatez des différences sur vos pages.
Données de laboratoire par rapport aux données sur le terrain
Pour comprendre pourquoi les outils de laboratoire et sur le terrain peuvent afficher des valeurs différentes, même pour la même page Web, vous devez connaître la différence entre les données de laboratoire et celles sur le terrain.
Données de l'atelier
Les données de laboratoire sont déterminées en chargeant une page Web dans un environnement contrôlé avec un ensemble prédéfini de conditions réseau et d'appareil. Ces conditions sont appelées environnement laboratoire, parfois aussi appelé environnement synthétique.
Les outils Chrome qui génèrent des données de laboratoire exécutent généralement Lighthouse.
L'objectif d'un test en laboratoire est de contrôler autant de facteurs que possible afin que les résultats soient (dans la mesure du possible) cohérents et reproductibles d'une exécution à l'autre.
Données de champ
Les données de champ sont déterminées en surveillant tous les utilisateurs qui accèdent à une page et en mesurant un ensemble donné de métriques de performances pour chacune des expériences individuelles de ces utilisateurs. Étant donné que les données sur le terrain sont basées sur les visites d'utilisateurs réels, elles reflètent les appareils, les conditions réseau et les emplacements géographiques réels de vos utilisateurs.
Les données de champ sont également communément appelées données de surveillance des utilisateurs réels (RUM). Les deux termes sont interchangeables.
Les outils Chrome qui génèrent des données sur le terrain les obtiennent généralement à partir du rapport d'expérience utilisateur Chrome (CrUX). Il est également courant (et recommandé) que les propriétaires de sites collectent eux-mêmes des données sur le terrain, car cela peut fournir des insights plus exploitables que l'utilisation de CrUX seul.
Le point le plus important à comprendre concernant les données sur le terrain est qu'il ne s'agit pas d'un seul nombre, mais d'une distribution de nombres. Autrement dit, le chargement de votre site peut être très rapide pour certains utilisateurs, mais très lent pour d'autres. Les données de terrain de votre site sont l'ensemble complet de toutes les données de performances collectées auprès de vos utilisateurs.
Par exemple, les rapports CrUX affichent la distribution des métriques de performances des utilisateurs Chrome réels sur une période de 28 jours. Si vous examinez presque n'importe quel rapport CrUX, vous pouvez constater que certains utilisateurs qui visitent un site peuvent avoir une très bonne expérience, tandis que d'autres peuvent avoir une expérience très mauvaise.
Si un outil indique un seul nombre pour une métrique donnée, il représente généralement un point spécifique de la distribution. Les outils qui indiquent les scores des champs Core Web Vitals le font à l'aide du 75e percentile.
En examinant le LCP à partir des données de terrain de la capture d'écran ci-dessus, vous pouvez voir une distribution dans laquelle:
- 88% des visites ont enregistré un LCP de 2,5 secondes ou moins (bon).
- 8% des visites ont enregistré un LCP compris entre 2,5 et 4 secondes (à améliorer).
- 4% des visites ont enregistré un LCP supérieur à 4 secondes (mauvais).
Au 75e centile, le LCP était de 1,8 seconde:
Les données de l'atelier de la même page indiquent une valeur LCP de 3,0 seconde. Bien que cette valeur soit supérieure aux 1,8 secondes indiquées dans les données sur le terrain, il s'agit toujours d'une valeur LCP valide pour cette page.Il s'agit de l'une des nombreuses valeurs qui constituent la distribution complète des expériences de chargement.
Pourquoi les données de laboratoire et de terrain sont-elles différentes ?
Comme indiqué dans la section ci-dessus, les données de laboratoire et les données sur le terrain mesurent en réalité des choses très différentes.
Les données sur le terrain incluent une grande variété de conditions de réseau et d'appareil, ainsi qu'une multitude de types de comportement utilisateur. Il inclut également tous les autres facteurs qui affectent l'expérience utilisateur, tels que les optimisations du navigateur, comme le cache avant/arrière (bfcache), ou les optimisations de la plate-forme, comme le cache AMP.
En revanche, les données de laboratoire limitent intentionnellement le nombre de variables impliquées. Un test en laboratoire se compose des éléments suivants:
- Un seul appareil…
- connectés à un seul réseau ;
- sont exécutées à partir d'un seul emplacement géographique.
Les caractéristiques de tout test en laboratoire donné peuvent ou non représenter avec précision le 75e centile des données sur le terrain pour une page ou un site donnés.
L'environnement contrôlé du laboratoire est utile pour déboguer des problèmes ou tester des fonctionnalités avant de les déployer en production. Toutefois, lorsque vous contrôlez ces facteurs, vous ne représentez pas explicitement la variance que vous voyez dans le monde réel pour tous les types de réseaux, les fonctionnalités des appareils ou les zones géographiques. Vous ne capturez généralement pas non plus l'impact des performances sur le comportement des utilisateurs réels, comme le défilement, la sélection de texte ou le tapotement sur des éléments de la page.
En plus du décalage possible entre les conditions de laboratoire et celles de la plupart des utilisateurs réels, il existe également un certain nombre de différences plus subtiles qu'il est important de comprendre pour tirer le meilleur parti de vos données de laboratoire et sur le terrain, ainsi que de toute différence que vous pourriez constater.
Les sections suivantes détaillent les raisons les plus courantes pour lesquelles il peut y avoir des différences entre les données de laboratoire et les données sur le terrain pour chacune des métriques Core Web Vitals:
LCP
Différents éléments LCP
L'élément LCP identifié dans un test en laboratoire peut ne pas être le même que celui que les utilisateurs voient lorsqu'ils accèdent à votre page.
Si vous exécutez un rapport Lighthouse pour une page donnée, il renverra toujours le même élément LCP. Toutefois, si vous examinez les données de champ pour la même page, vous trouverez généralement différents éléments de LCP, qui dépendent d'un certain nombre de circonstances spécifiques à chaque visite de page.
Par exemple, les facteurs suivants peuvent tous contribuer à la détermination d'un élément LCP différent pour la même page:
- Les différentes tailles d'écran des appareils entraînent l'affichage de différents éléments dans la fenêtre d'affichage.
- Si l'utilisateur est connecté ou si du contenu personnalisé est affiché d'une manière ou d'une autre, l'élément LCP peut être très différent d'un utilisateur à l'autre.
- Comme pour le point précédent, si un test A/B est exécuté sur la page, des éléments très différents peuvent s'afficher.
- L'ensemble de polices installées sur le système de l'utilisateur peut avoir une incidence sur la taille du texte sur la page (et donc sur l'élément qui est l'élément LCP).
- Les tests en laboratoire sont généralement exécutés sur l'URL de base d'une page, sans aucun paramètre de requête ni fragment de hachage ajouté. Toutefois, dans la pratique, les utilisateurs partagent souvent des URL contenant un identifiant de fragment ou un fragment de texte. L'élément LCP peut donc se trouver au milieu ou en bas de la page (plutôt qu'au-dessus de la ligne de flottaison).
Étant donné que le LCP dans le champ est calculé comme le 75e percentile de toutes les visites d'utilisateurs sur une page, si un pourcentage élevé de ces utilisateurs ont un élément LCP qui se charge très rapidement (par exemple, un paragraphe de texte affiché avec une police système), même si certains de ces utilisateurs ont une image volumineuse et lente à charger comme élément LCP, cela peut ne pas affecter le score de cette page si cela se produit pour moins de 25 % des visiteurs.
L'inverse pourrait également être vrai. Un test en laboratoire peut identifier un bloc de texte comme élément LCP, car il émule un téléphone Moto G4 dont la fenêtre d'affichage est relativement petite et dont l'image hero de votre page est initialement affichée en dehors de l'écran. Toutefois, vos données sur le terrain peuvent inclure principalement des utilisateurs de Pixel XL avec des écrans plus grands. Pour eux, l'image principale qui se charge lentement est leur élément LCP.
Effets de l'état du cache sur le LCP
Les tests en laboratoire chargent généralement une page avec un cache froid, mais lorsque de véritables utilisateurs consultent cette page, certaines de ses ressources peuvent déjà être mises en cache.
La première fois qu'un utilisateur charge une page, son chargement peut être lent. Toutefois, si la page est correctement mise en cache, la prochaine fois que cet utilisateur y accédera, la page pourra se charger immédiatement.
Bien que certains outils de laboratoire acceptent plusieurs exécutions de la même page (pour simuler l'expérience des visiteurs réguliers), il n'est pas possible pour un outil de laboratoire de savoir quel pourcentage de visites réelles est effectué par des nouveaux utilisateurs par rapport aux utilisateurs réguliers.
Les sites dont les configurations de cache sont bien optimisées et qui enregistrent de nombreux visiteurs réguliers peuvent découvrir que leur LCP réelle est beaucoup plus rapide que ce que leurs données de laboratoire indiquent.
Optimisations AMP ou d'échanges signés
Les sites créés avec AMP ou qui utilisent des échanges signés (SXG) peuvent être préchargés par des agrégateurs de contenu comme la recherche Google. Cela peut considérablement améliorer les performances de chargement pour les utilisateurs qui accèdent à vos pages depuis ces plates-formes.
En plus du préchargement inter-origine, les sites eux-mêmes peuvent précharger le contenu des pages suivantes de leur site, ce qui peut également améliorer le LCP de ces pages.
Les outils de laboratoire ne simulent pas les gains obtenus grâce à ces optimisations. Et même s'ils le faisaient, ils ne pourraient pas savoir quel pourcentage de votre trafic provient de plates-formes comme la recherche Google par rapport à d'autres sources.
Effets du bfcache sur le LCP
Lorsque les pages sont restaurées à partir du bfcache, l'expérience de chargement est presque instantanée, et ces expériences sont incluses dans vos données de champ.
Les tests en laboratoire ne prennent pas en compte bfcache. Par conséquent, si vos pages sont compatibles avec bfcache, les scores LCP seront probablement plus rapides dans le champ.
Effets de l'interaction utilisateur sur le LCP
Le LCP identifie le délai d'affichage du plus grand bloc d'image ou de texte dans la fenêtre d'affichage, mais cet élément le plus grand peut changer au fur et à mesure du chargement de la page ou si de nouveaux contenus sont ajoutés de manière dynamique à la fenêtre d'affichage.
Dans l'atelier, le navigateur attend que la page soit entièrement chargée avant de déterminer l'élément LCP. Toutefois, dans la pratique, le navigateur arrête de surveiller les éléments plus volumineux une fois que l'utilisateur fait défiler la page ou interagit avec elle.
Cela est logique (et nécessaire), car les utilisateurs attendent généralement d'interagir avec une page jusqu'à ce qu'elle "semble" chargée, ce qui est exactement ce que la métrique LCP vise à détecter. Il serait également illogique de prendre en compte les éléments ajoutés au viewport après une interaction de l'utilisateur, car ces éléments n'ont peut-être été chargés que en raison d'une action de l'utilisateur.
Cela implique toutefois que les données d'utilisation réelles d'une page peuvent indiquer des temps de chargement de la page plus rapides, en fonction du comportement des utilisateurs sur cette page.
INP
L'INP nécessite une interaction avec un utilisateur réel
La métrique INP mesure la réactivité d'une page aux interactions des utilisateurs, au moment où les utilisateurs choisissent de l'interagir.
La deuxième partie de cette phrase est essentielle, car les tests en laboratoire, même ceux qui prennent en charge le comportement des utilisateurs du script, ne peuvent pas prédire avec précision quand les utilisateurs choisiront d'interagir avec une page et ne peuvent donc pas mesurer avec précision le FID.
La fonctionnalité TBT ne tient pas compte du comportement des utilisateurs.
La métrique Total Blocking Time (TBT) de l'environnement de test vise à aider à diagnostiquer les problèmes liés à l'INP, car elle quantifie le blocage du thread principal pendant le chargement de la page.
L'idée est que les pages contenant beaucoup de code JavaScript synchrone ou d'autres tâches de rendu intensives ont plus de chances d'avoir un thread principal bloqué lorsque l'utilisateur interagit pour la première fois. Toutefois, si les utilisateurs attendent d'interagir avec la page jusqu'à la fin de l'exécution du code JavaScript, l'INP peut être très faible.
Le moment où les utilisateurs choisiront d'interagir avec une page dépend en grande partie de son apparence interactive ou non, ce qui ne peut pas être mesuré avec le TBT.
Le TBT ne tient pas compte du délai de pression
Si un site n'est pas optimisé pour la consultation sur mobile, les navigateurs ajoutent un délai de 300 ms après chaque appui avant d'exécuter les gestionnaires d'événements. Ils doivent en effet déterminer si l'utilisateur tente d'appuyer deux fois pour zoomer avant de pouvoir déclencher des événements de souris ou de clic.
Ce délai est pris en compte dans l'INP d'une page, car il contribue à la latence d'entrée réelle que les utilisateurs rencontrent. Toutefois, comme ce délai n'est techniquement pas une tâche longue, il n'affecte pas le TBT d'une page. Par conséquent, une page peut avoir un INP médiocre malgré des scores TBT très bons.
Effets de l'état du cache et de bfcache sur l'INP
De la même manière que la mise en cache appropriée peut améliorer le LCP sur le terrain, elle peut également améliorer l'INP.
Dans la pratique, il est possible qu'un utilisateur dispose déjà du code JavaScript d'un site dans son cache. Le traitement peut donc prendre moins de temps et entraîner des délais plus courts.
Il en va de même pour les pages restaurées à partir de bfcache. Dans ce cas, le code JavaScript est restauré à partir de la mémoire. Le temps de traitement peut donc être très court, voire nul.
CLS
Effets de l'interaction utilisateur sur le CLS
Le CLS mesuré en laboratoire ne prend en compte que les décalages de mise en page qui se produisent au-dessus du pli et lors du chargement, mais il ne s'agit que d'un sous-ensemble de ce que le CLS mesure réellement.
Sur le terrain, le CLS tient compte de tous les décalages de mise en page inattendus qui se produisent tout au long de la durée de vie de la page, y compris du contenu qui se déplace lorsque l'utilisateur fait défiler la page ou en réponse à des requêtes réseau lentes après une interaction utilisateur.
Par exemple, il est assez courant que les pages chargent de manière différée des images ou des iFrames sans dimensions, ce qui peut entraîner des décalages de mise en page lorsqu'un utilisateur fait défiler ces sections de la page. Toutefois, ces décalages ne se produisent que si l'utilisateur fait défiler l'écran vers le bas, ce qui n'est souvent pas détecté lors d'un test en laboratoire.
Contenu personnalisé
Le contenu personnalisé (y compris les annonces ciblées et les tests A/B) affecte les éléments chargés sur une page. Cela affecte également la façon dont ils sont chargés, car le contenu personnalisé est souvent chargé plus tard et inséré dans le contenu principal d'une page, ce qui entraîne des décalages de mise en page.
Dans le laboratoire, une page est généralement chargée sans contenu personnalisé ou avec du contenu pour un "utilisateur test" générique, ce qui peut ou non déclencher les changements que les utilisateurs réels voient.
Étant donné que les données de champ incluent les expériences de tous les utilisateurs, la quantité (et le degré) de décalages de mise en page sur une page donnée dépend fortement du contenu chargé.
Effets de l'état du cache et de bfcache sur CLS
Deux des causes les plus courantes de changements de mise en page lors du chargement sont les images et les iFrames sans dimensions (comme indiqué ci-dessus) et les polices Web à chargement lent. Ces deux problèmes sont plus susceptibles d'affecter l'expérience lorsque l'utilisateur accède à un site pour la première fois, lorsque son cache est vide.
Si les ressources d'une page sont mises en cache ou si la page elle-même est restaurée à partir de bfcache, le navigateur peut généralement afficher les images et les polices immédiatement, sans attendre qu'elles soient téléchargées. Cela peut entraîner des valeurs CLS plus faibles sur le terrain que celles indiquées par un outil de laboratoire.
Que faire lorsque les résultats sont différents ?
En règle générale, si vous disposez à la fois de données sur le terrain et de données de laboratoire pour une page donnée, vous devez utiliser les données sur le terrain pour hiérarchiser vos efforts. Étant donné que les données sur le terrain représentent ce que les utilisateurs réels vivent, il s'agit du moyen le plus précis de comprendre vraiment les difficultés de vos utilisateurs et ce qui doit être amélioré.
À l'inverse, si vos données sur le terrain affichent de bons scores dans l'ensemble, mais que vos données de laboratoire suggèrent qu'il y a encore des améliorations à apporter, il est utile de comprendre quelles optimisations supplémentaires peuvent être effectuées.
De plus, bien que les données sur le terrain capturent les expériences des utilisateurs réels, elles ne le font que pour les utilisateurs qui parviennent à charger votre site. Les données de laboratoire peuvent parfois vous aider à identifier des opportunités d'élargir la couverture de votre site et de le rendre plus accessible aux utilisateurs disposant de réseaux plus lents ou d'appareils moins performants.
Dans l'ensemble, les données de laboratoire et les données sur le terrain sont des éléments importants pour mesurer efficacement les performances. Chacune d'elles a ses avantages et ses limites. Si vous n'en utilisez qu'une seule, vous risquez de passer à côté d'une opportunité d'améliorer l'expérience pour vos utilisateurs.