Découvrez pourquoi les outils qui surveillent les métriques Core Web Vitals peuvent fournir des chiffres différents et comment interpréter ces différences.
Google fournit différents outils pour aider les propriétaires de sites à surveiller leurs scores Core Web Vitals. Ces outils se répartissent en deux catégories principales:
- Les outils générant des rapports sur les données de laboratoire (données collectées dans un environnement contrôlé avec paramètres prédéfinis des appareils et des réseaux.
- Les outils de création de rapports sur les données réelles, c'est-à-dire les données collectées auprès des utilisateurs réels visitant le site sur votre site.
Le problème est que parfois, les données rapportées par les outils de laboratoire peuvent être différent de celles rapportées par les outils de terrain ! Les données de l'atelier peuvent indiquer que votre site est performant, mais que vos données réelles suggèrent qu'il a besoin d'amélioration. Les données de champs peuvent aussi indiquer que toutes vos pages sont bonnes, vos données de laboratoire peuvent afficher un score très faible.
L'exemple réel suivant de rapport PageSpeed Insights de web.dev montre que, dans certains cas, les données de terrain et de laboratoire peuvent être différentes Métriques Web Vitals:
Les différences entre les outils sont une source de confusion compréhensible pour développeurs. Cet article explique les principales raisons pour lesquelles ces différences avec des exemples spécifiques couvrant chacune des métriques Core Web Vitals. que faire si vous constatez des différences sur vos pages.
Données de laboratoire et données réelles
Pour comprendre pourquoi les outils de laboratoire et de terrain peuvent indiquer des valeurs différentes, même pour le exactement la même page Web, vous devez comprendre la différence entre l'atelier et le terrain données.
Données de test
Les données de l'atelier sont déterminées en chargeant une page Web dans un environnement contrôlé avec un ensemble prédéfini de conditions de réseau et d'appareil. Ces conditions sont appelées lab, parfois également appelé environnement synthetic.
Les outils Chrome qui signalent les données de laboratoire sont généralement en cours d'exécution Phare :
L'objectif d'un test de laboratoire est de contrôler autant de facteurs que possible, afin que les résultats sont (dans la mesure du possible) cohérents et reproductibles d'une exécution à l'autre.
Données des champs
Les données de champ sont déterminées en surveillant tous les utilisateurs qui consultent une page et en mesurant un ensemble de métriques de performances pour chacun de ces utilisateurs individuel expériences. Étant donné que les données réelles sont basées sur les visites effectuées par des utilisateurs réels, elles reflètent les appareils réels, les conditions du réseau et les emplacements géographiques de vos utilisateurs.
Les données de terrain sont également appelées Real User Monitoring (RUM), les deux termes sont interchangeables.
Les outils Chrome qui génèrent des rapports sur les données des champs obtiennent généralement ces données depuis l'outil Chrome Rapport sur l'expérience utilisateur (CrUX). Il est également courant (et recommandé) que les propriétaires de sites collectent des données réelles elles-mêmes, car elles peuvent fournir d'insights plus exploitables que l'utilisation simple de l'expérience utilisateur Chrome.
La chose la plus importante à comprendre à propos des données de champ est qu'elles ne concernent pas seulement un nombre, c'est une distribution de nombres. Autrement dit, pour certaines personnes qui visitent votre site, il peut se charger très rapidement, alors que pour d'autres, il peut se charger très lentement. Les données de champ pour votre site correspondent à l'ensemble complet des données de performances. collectées auprès de vos utilisateurs.
Par exemple, les rapports d'expérience utilisateur Chrome fournissent une répartition des métriques de performances Utilisateurs de Chrome sur une période de 28 jours Si vous consultez presque tous les rapports CrUX, que certains visiteurs d'un site bénéficient d'une très bonne expérience d’autres pourraient avoir une très mauvaise expérience.
Si un outil fournit un seul nombre pour une métrique donnée, il indique généralement représentent un point spécifique de la distribution. Outils de création de rapports sur les Core Web Pour les statistiques de statistiques Android Vitals, le score 75 centile.
En examinant le LCP à partir des données réelles de la capture d'écran ci-dessus, vous pouvez voir distribution où:
- 88% des visites ont enregistré un LCP de 2,5 secondes ou moins (bon).
- Pour 8% des visites, le LCP était compris entre 2,5 et 4 secondes (amélioration nécessaire).
- Pour 4% des visites, le LCP était supérieur à 4 secondes (mauvais).
Au 75e centile, le LCP était de 1,8 seconde:
Les données de laboratoire de la même page affichent une valeur LCP de 3,0 seconde. Bien que cette valeur supérieure à la durée de 1,8 seconde indiquée dans les données de champ, il s'agit toujours d'un LCP valide pour cette page, car il s'agit de l'une des nombreuses valeurs qui composent la distribution complète de chargement.
Pourquoi les données de laboratoire et les données réelles sont-elles différentes ?
Comme l'explique la section ci-dessus, les données de laboratoire et les données de terrain mesurent des choses différentes.
Les données de terrain incluent une grande variété de conditions relatives aux réseaux et aux appareils, ainsi qu'un une myriade de types de comportements d'utilisateurs différents. Cela inclut également tout autre facteur qui ont un impact sur l'expérience utilisateur, comme l'optimisation du navigateur cache amélioré (bfcache), ou des optimisations de plate-forme telles que AMP Cache.
En revanche, les données de l'atelier limitent intentionnellement le nombre de variables impliquées. A le test de l'atelier comprend:
- Un seul appareil...
- connecté à un même réseau...
- à partir d'un emplacement géographique unique.
Les caractéristiques d'un test de laboratoire donné peuvent ou non représenter avec précision 75e centile des données de champ pour une page ou un site donnés.
L'environnement contrôlé de l'atelier est utile pour déboguer des problèmes ou effectuer des tests avant le déploiement en production, mais si vous contrôlez ces facteurs vous ne représentez pas clairement la variance que vous voyez dans le monde réel sur tous les types de réseaux, les fonctionnalités des appareils ou les emplacements géographiques. Toi ne capturent généralement pas l'impact sur les performances du comportement réel des utilisateurs, comme faire défiler, sélectionner du texte ou appuyer sur des éléments de la page.
En plus d'une éventuelle dissociation entre les conditions du laboratoire et les conditions de la plupart des utilisateurs du monde réel, il existe également un certain nombre de différences plus subtiles à comprendre pour tirer le meilleur parti de l'atelier. et les données de champ, ainsi que toute différence éventuelle.
Les sections suivantes expliquent en détail les raisons les plus courantes il peut y avoir des différences entre les données de laboratoire et les données réelles pour chacun des serveurs Core Web Métriques Vitals:
LCP
Différents éléments LCP
L'élément LCP identifié dans un test de laboratoire peut être différent du LCP que les utilisateurs voient lorsqu'ils visitent votre page.
Si vous générez un rapport Lighthouse pour une page donnée, le même résultat sera renvoyé l'élément LCP à chaque fois. En revanche, si vous examinez les données de champ pour une même page, vous trouverez généralement une variété d'éléments LCP différents, qui dépendent d'une le nombre de circonstances spécifiques à chaque visite de page.
Par exemple, les facteurs suivants peuvent tous contribuer à un LCP différent déterminé pour la même page:
- Des éléments différents sont visibles en fonction de la taille d'écran des appareils dans la fenêtre d'affichage.
- Si l'utilisateur est connecté ou si du contenu personnalisé s'affiche dans certains l'élément LCP peut être très différent d'un utilisateur à l'autre.
- De même qu'à l'étape précédente, si un test A/B est en cours d'exécution sur la page, qui entraînent l'affichage d'éléments très différents.
- L'ensemble des polices installées sur le système de l'utilisateur peut avoir une incidence sur la taille du texte la page (et donc quel élément constitue l'élément LCP).
- Les tests labo sont généralement exécutés sur la "base" d'une page URL, sans paramètres de requête ou fragments de hachage ajoutés. Mais en réalité, les utilisateurs partagent souvent des URL contenant un identifiant de fragment ou fragment de texte, de sorte que l'élément LCP peut se trouver au milieu ou en bas de la page (plutôt que "au-dessus du plier").
Le LCP du champ correspondant au 75e centile de toutes les visites des utilisateurs à une page, si un grand pourcentage de ces utilisateurs disposaient d'un élément LCP chargé très rapidement (par exemple, un paragraphe de texte rendu avec une police système), puis même si le LCP de certains de ces utilisateurs comportait une image volumineuse et à chargement lent il est possible que le score de la page ne soit pas affecté si le taux est inférieur à 25 %. des visiteurs.
L'inverse peut également être vrai. Un test de laboratoire peut identifier un bloc de comme élément LCP, car il émule un téléphone Moto G4 doté d'un fenêtre d'affichage relativement petite et l'image héros de votre page s'affiche initialement en dehors de l'écran. Toutefois, vos données réelles peuvent inclure principalement des utilisateurs de Pixel XL ayant sur les grands écrans. Pour eux, l'image héros 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 vrais utilisateurs visitent cette page, il est possible que certaines de ses ressources soient déjà mises en cache.
La première fois qu'un utilisateur charge une page, elle peut se charger lentement. Toutefois, si la page comporte mise en cache correctement configurée, la prochaine fois que l'utilisateur renvoie peut se charger immédiatement.
Certains outils de l'atelier acceptent plusieurs exécutions de la même page (pour simuler la pour les visiteurs connus), il n'est pas possible pour un outil de laboratoire de savoir le pourcentage de visites réelles générées par des utilisateurs nouveaux par rapport aux utilisateurs connus ;
Les sites dont la configuration du cache est bien optimisée et qui attirent de nombreux visiteurs récurrents découvrir que son LCP réel est beaucoup plus rapide que ses données de laboratoire ne le révèlent.
Optimisations d'AMP ou d'échange signé
Sites conçus au format AMP ou utilisant les échanges signés (SXG) peuvent être préchargés par des agrégateurs de contenu comme Google Rechercher. Cela peut considérablement améliorer les performances de chargement pour les utilisateurs. qui consultent vos pages à partir de ces plates-formes.
En plus du préchargement multi-origine, les sites peuvent eux-mêmes précharger le contenu des pages suivantes sur son site ; ce qui pourrait également améliorer le LCP de ces pages.
Les outils de l'atelier ne simulent pas les gains obtenus grâce à ces optimisations, et même si ils ne pouvaient pas connaître le pourcentage de votre trafic plates-formes comme la recherche Google par rapport à d'autres sources.
Effets du cache amélioré sur le LCP
Lorsque les pages sont restaurées à partir du cache amélioré, l'expérience de chargement est proche instantanée, et ces expériences sont incluses dans votre domaine données.
Les tests labo ne tiennent pas compte du cache amélioré, donc si vos pages sont sont compatibles avec le cache amélioré, ce qui se traduit par des scores LCP plus rapides sur le terrain.
Effets de l'interaction utilisateur sur le LCP
Le LCP identifie le délai d'affichage de l'image ou du bloc de texte le plus grand de la mais l'élément le plus grand peut changer à mesure que la page se charge ou le contenu est ajouté de façon dynamique à la fenêtre d'affichage.
Au cours de l'atelier, le navigateur attendra que la page soit entièrement chargée avant pour déterminer quel était l'élément LCP. En revanche, sur le terrain, le navigateur s'arrête de surveillance pour les éléments plus grands après que l'utilisateur a fait défiler la page ou a interagi avec elle.
C'est logique (et nécessaire), car les utilisateurs attendent généralement interagir avec une page jusqu'à ce qu'elle "apparaisse" ce qui correspond exactement au LCP que vous souhaitez détecter. Il n'aurait pas non plus de sens de considérer les éléments ajoutés à la fenêtre d'affichage après une interaction de l'utilisateur, car il est possible que ces éléments chargé à cause d'une action effectuée par l'utilisateur.
Il en résulte que les données de champ d'une page peuvent générer des rapports plus rapidement Les heures LCP, en fonction du comportement des utilisateurs sur cette page.
INP
INP nécessite une interaction réelle de l'utilisateur
La métrique INP mesure la réactivité d'une page aux interactions des utilisateurs, au moment où les utilisateurs décident d'interagir avec elle.
La deuxième partie de cette phrase est essentielle, car les tests de laboratoire, même ceux qui script d'assistance concernant le comportement des utilisateurs, impossible de 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é de navigation détaillée ne tient pas compte du comportement des utilisateurs
La métrique de l'atelier Temps de blocage total (TBT) est conçue pour vous aider à diagnostiquer les problèmes liés à INP, car elle quantifie le degré de blocage du thread principal pendant le chargement de la page.
L'idée est que les pages comportant beaucoup de code JavaScript synchrone ou d'autres les tâches d'affichage sont plus susceptibles 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 l'exécution du code JavaScript se termine, l'INP peut être très faible.
Le moment où les utilisateurs décident d'interagir avec une page dépend en grande partie du fait qu'ils cela semble interactif et ne peut pas être mesuré à l'aide de la technique de navigation détaillée.
La fonctionnalité de ciblage par transaction ne tient pas compte du délai de paiement sans contact.
Si le site n'est pas optimisé pour l'affichage sur mobile, les navigateurs ajoutent un délai supplémentaire de 300 ms retard après un appui avant d'exécuter des gestionnaires d'événements. Ils le font parce qu’ils doivent Déterminer si l'utilisateur essaie d'appuyer deux fois pour zoomer avant de déclencher les événements de souris ou de clic.
Ce délai est comptabilisé dans l'INP d'une page, car il contribue à l'entrée réelle la latence que rencontrent les utilisateurs. Mais comme ce délai n'est techniquement pas un Long tâche, cela n'affecte pas la fonctionnalité de navigation détaillée d'une page. Cela signifie qu'une page peut avoir un INP médiocre bien qu'il ait de très bons scores de TAT.
Effets de l'état du cache et du cache amélioré sur INP
De la même manière qu'une mise en cache appropriée peut améliorer le LCP sur le terrain, elle peut aussi améliorer INP.
Dans le monde réel, un utilisateur peut avoir le JavaScript d'un site déjà dans sa et leur traitement prend moins de temps de temps à autre, ce qui réduit les délais.
Il en va de même pour les pages restaurées à partir de bfcache. Dans ce cas, JavaScript est restauré à partir de la mémoire. Le traitement peut donc être limité ou inexistant. à tout moment.
CLS
Effets de l'interaction utilisateur sur le CLS
Le CLS mesuré dans l'atelier ne prend en compte que les décalages de mise en page qui se produisent au-dessus la ligne de flottaison et pendant le chargement, mais il ne s'agit là que d'un sous-ensemble les mesures correctives.
Sur le terrain, le CLS prend en compte toutes les mises en page inattendues changements qui surviennent tout au long du durée de vie de la page, y compris le contenu qui se déplace lorsque l'utilisateur fait défiler la page ou en réponse aux requêtes réseau lentes après une interaction de l'utilisateur.
Par exemple, il n'est pas rare que les pages chargent des images ou des iFrames sans des dimensions, ce qui peut entraîner une mise en page se déplace lorsque l'utilisateur fait défiler l'écran jusqu'à ces sections de la page. Mais ces changements peuvent ne se produisent que si l'utilisateur fait défiler la page vers le bas, ce qui n'est souvent pas détecté lors d'un test de laboratoire.
Contenu personnalisé
Le contenu personnalisé (y compris les annonces ciblées et les tests A/B) a une incidence sur les éléments sont chargés sur une page. Cela affecte également la façon dont elles sont chargées, car les personnalisations le contenu est souvent chargé ultérieurement et inséré dans le contenu principal d'une page, ce qui entraîne décalages de mise en page.
Dans cet atelier, une page est généralement chargée sans contenu personnalisé, ou avec du contenu pour un "utilisateur test" générique, qui peut ou non déclencher les changements que voient les utilisateurs réels.
Étant donné que les données de terrain incluent les expériences de tous les utilisateurs, la quantité (et le degré) des décalages de mise en page rencontrés sur une page donnée dépendent beaucoup du contenu est chargé.
Effets de l'état du cache et du cache amélioré sur le CLS
Les décalages de mise en page lors du chargement sont deux des causes les plus courantes iFrame sans dimensions (comme mentionné ci-dessus) et Web à chargement lent et les polices de caractères. Ces deux problèmes sont plus susceptibles affectent l'expérience la première fois qu'un utilisateur accède à un site, 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 le cache amélioré, le navigateur peut généralement afficher les images et les polices immédiatement, en attente de téléchargement. Cela peut entraîner une diminution des valeurs CLS dans le champ que celui d'un outil de laboratoire.
Que faire lorsque les résultats sont différents ?
En règle générale, si vous avez à la fois des données réelles et des données de laboratoire pour une page donnée, les données de terrain sont ce que vous devriez utiliser pour hiérarchiser vos efforts. Puisque les données de champ représente ce que vivent les utilisateurs, c'est le moyen le plus précis comprendre ce qui pose problème à vos utilisateurs et ce qui doit être s'améliorent.
D’un autre côté, si vos données de terrain montrent de bons scores à tous les niveaux, mais vos données de laboratoire suggèrent qu'il est encore possible de s'améliorer, cela vaut la peine et de comprendre les optimisations pouvant être apportées.
De plus, si les données de terrain capturent des expériences utilisateur réelles, elles ne font que donc pour ceux qui réussissent à charger votre site. Les données de laboratoire peuvent permettent parfois d'identifier des opportunités d'élargir l'audience de votre site plus accessible aux utilisateurs dont les réseaux sont plus lents ou les appareils bas de gamme.
Globalement, les données de laboratoire et les données de terrain sont des éléments importants de la la mesure des performances. Ils ont tous les deux leurs forces et leurs limites, et si si vous n'en utilisez qu'un seul, vous risquez de manquer une occasion d'améliorer pour vos utilisateurs.