Découvrez pourquoi les outils qui surveillent les métriques Core Web Vitals peuvent indiquer des chiffres différents et comment interpréter ces différences.
Google fournit plusieurs outils pour aider les propriétaires de sites à surveiller leur score Core Web Vitals. Ces outils se répartissent en deux catégories principales:
- Outils générant des rapports sur les données de test : données collectées dans un environnement contrôlé avec des paramètres d'appareil et de réseau prédéfinis
- Outils qui génèrent des rapports sur les données réelles : données collectées auprès des utilisateurs réels qui consultent votre site
Le problème est que parfois, les données signalées par les outils de l'atelier peuvent être légèrement différentes de celles signalées par les outils de terrain. Vos données de test indiquent peut-être que votre site est performant, mais vos données réelles indiquent qu'il doit être amélioré. Vos données de terrain peuvent également indiquer que toutes vos pages sont bonnes, alors que vos données de test peuvent indiquer un score très faible.
L'exemple réel suivant de rapport PageSpeed Insights issu de web.dev montre que, dans certains cas, les données de test et de 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 pour lesquelles ces différences peuvent exister. Des exemples spécifiques couvrent chacune des métriques Core Web Vitals, et comment procéder si vous constatez des différences sur vos pages.
Données de test et données réelles
Pour comprendre pourquoi les outils de test et de terrain peuvent indiquer des valeurs différentes, même pour une seule et même page Web, vous devez comprendre la différence entre les données de test et les données réelles.
Données de test
Les données de test sont déterminées en chargeant une page Web dans un environnement contrôlé avec un ensemble prédéfini de conditions relatives au réseau et à l'appareil. C'est ce que l'on appelle un environnement d'atelier, parfois également appelé environnement synthétique.
Les outils Chrome qui génèrent des rapports sur les données de test s'exécutent généralement sous Lighthouse.
L'objectif d'un test de laboratoire est de contrôler autant de facteurs que possible, afin que les résultats soient (autant que 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 consultent une page et en mesurant un ensemble donné de métriques de performances pour chacune de leurs expériences individuelles. Les données réelles étant basées sur les visites d'utilisateurs réels, elles reflètent les appareils, l'état du 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 RUM (Real User Monitoring). Les deux termes sont interchangeables.
Les outils Chrome qui communiquent des données réelles proviennent généralement du rapport d'expérience utilisateur Chrome. Il est également courant (et recommandé) pour les propriétaires de sites de collecter eux-mêmes des données de terrain, car cela leur permet de fournir des insights plus exploitables qu'en utilisant uniquement CrUX.
La chose la plus importante à comprendre concernant les données de champ est qu'il ne s'agit pas d'un nombre, mais d'une distribution de nombres. Autrement dit, le chargement peut être très rapide pour certains visiteurs, alors que pour d'autres, il peut se charger très lentement. Les données de champ de votre site constituent l'ensemble complet de toutes les données de performances collectées auprès de vos utilisateurs.
Par exemple, les rapports CrUX indiquent la répartition des métriques de performances des vrais utilisateurs de Chrome sur une période de 28 jours. Si vous consultez presque tous les rapports CrUX, vous pouvez constater que certains utilisateurs qui visitent un site peuvent bénéficier d'une très bonne expérience, tandis que d'autres peuvent en être moins satisfaits.
Si un outil indique un seul nombre pour une métrique donnée, il représentera généralement un point spécifique de la distribution. Les outils qui enregistrent les scores de champ Core Web Vitals le font à l'aide du 75e centile.
En examinant le LCP à partir des données de champ 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élioration nécessaire).
- 4% des visites ont enregistré un LCP supérieur à 4 secondes (médiocre).
Au 75e centile, le LCP était de 1,8 seconde:
Les données de test de la même page affichent une valeur LCP de 3 secondes. Bien que cette valeur soit supérieure aux 1,8 secondes indiquées dans les données de champ, elle reste une valeur LCP valide pour cette page.C'est l'une des nombreuses valeurs qui constituent la distribution complète des expériences de chargement.
Pourquoi les données de test sont-elles différentes des données réelles ?
Comme l'explique la section ci-dessus, les données de test et les données réelles mesurent des éléments très différents.
Les données réelles incluent une grande variété de conditions de réseau et d'appareil, ainsi qu'une multitude de types de comportements utilisateur différents. Il inclut également tous les autres facteurs affectant l'expérience utilisateur, tels que les optimisations de navigateur comme le cache amélioré (bfcache) ou les optimisations de plate-forme comme le cache AMP.
En revanche, les données de test limitent intentionnellement le nombre de variables impliquées. Un test d'atelier comprend les éléments suivants:
- Un seul appareil...
- connecté à un seul réseau...
- sont exécutés depuis un seul emplacement géographique.
Les caractéristiques d'un test de laboratoire donné peuvent ou non représenter avec précision le 75e centile des données réelles pour une page ou un site donnés.
L'environnement contrôlé de l'atelier 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 observez dans le monde réel sur tous les types de réseaux, les capacités des appareils ou les emplacements géographiques. De plus, vous ne capturez généralement pas l'impact sur les performances du comportement d'un utilisateur réel, tel que le défilement, la sélection de texte ou l'appui sur des éléments de la page.
Outre les éventuelles différences entre les conditions de test et celles de la plupart des utilisateurs réels, il existe un certain nombre de différences plus subtiles qu'il est important de comprendre afin d'exploiter au mieux vos données de test et de terrain, ainsi que les éventuelles différences que vous pouvez constater.
Les sections suivantes décrivent en détail les raisons les plus courantes pouvant expliquer les différences entre les données de test et les données réelles pour chacune des métriques Core Web Vitals:
LCP
Différents éléments LCP
L'élément LCP identifié dans un test de laboratoire peut être différent de l'élément LCP que les utilisateurs voient lorsqu'ils consultent votre page.
Si vous exécutez un rapport Lighthouse pour une page donnée, le même élément LCP sera renvoyé à chaque fois. Toutefois, si vous examinez les données des champs pour la même page, vous trouverez généralement différents éléments 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 autre élément LCP pour la même page:
- Différentes tailles d'écran d'appareils permettent de voir différents éléments dans la fenêtre d'affichage.
- Si l'utilisateur est connecté ou si du contenu personnalisé s'affiche d'une manière ou d'une autre, l'élément LCP peut être très différent d'un utilisateur à l'autre.
- Comme indiqué précédemment, si un test A/B est en cours d'exécution sur la page, il peut entraîner 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 de la page (et donc sur l'élément LCP).
- Les tests labo sont généralement exécutés sur l'URL de "base" d'une page, sans paramètres de requête ni fragments de hachage ajoutés. Mais en 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 que "au-dessus de la ligne de flottaison").
Étant donné que le LCP dans le champ est calculé comme le 75e centile de toutes les visites d'utilisateurs sur une page, si un pourcentage élevé de ces utilisateurs possédait un élément LCP qui se charge très rapidement (par exemple, un paragraphe de texte affiché avec une police système), alors même si certains de ces utilisateurs possédaient une grande image qui se charge lentement comme élément LCP, cela n'affecterait peut-être pas le score de cette page si le score de cette page est inférieur à 25 %.
L'inverse peut également se produire. 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 l'image héros de votre page est initialement affichée hors écran. Cependant, vos données réelles peuvent inclure principalement des utilisateurs de Pixel XL dotés d'écrans plus grands. Pour ces utilisateurs, l'image héros qui se charge lentement est donc leur élément LCP.
Effets de l'état du cache sur le LCP
Les tests labo permettent généralement de charger une page avec un cache froid, mais lorsque de vrais 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, celle-ci peut se charger lentement. Toutefois, si la mise en cache est correctement configurée, il se peut que la prochaine fois que l'utilisateur la renvoie, elle peut se charger immédiatement.
Certains outils d'atelier acceptent plusieurs exécutions de la même page (afin de simuler l'expérience pour les visiteurs connus), mais il est impossible pour un outil d'atelier de connaître le pourcentage de visites réelles effectuées par de nouveaux utilisateurs par rapport à des utilisateurs connus.
Les sites dotés de configurations de cache bien optimisées et de nombreux visiteurs récurrents peuvent découvrir que leur LCP réel est beaucoup plus rapide que ce qu'indiquent les données de test.
Optimisations d'AMP ou d'échange signé
Les sites conçus avec AMP ou qui utilisent des échanges signés (SXG) peuvent être préchargés par des agrégateurs de contenu tels que la recherche Google. Cela peut se traduire par de bien meilleures performances de chargement pour les utilisateurs qui consultent vos pages à partir de ces plates-formes.
En plus du préchargement multi-origine, les sites eux-mêmes peuvent précharger le contenu des pages suivantes de leur site, ce qui pourrait également améliorer le LCP de ces pages.
Les outils des ateliers ne simulent pas les gains observés par ces optimisations. Même si c'était le cas, ils ne pourraient pas connaître le pourcentage de votre trafic provenant de plates-formes telles que 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é, le chargement est presque instantané et ces expériences sont incluses dans vos données de champ.
Les tests de laboratoire ne tiennent pas compte du cache amélioré. Par conséquent, si vos pages sont compatibles avec le cache amélioré, les scores LCP obtenus sur le terrain seront probablement plus rapides.
Effets de l'interaction de l'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 lors du chargement de la page ou si du nouveau contenu est ajouté de manière dynamique à la fenêtre d'affichage.
Dans cet atelier, le navigateur attend que la page soit entièrement chargée avant de déterminer quel était l'élément LCP. Cependant, sur le terrain, le navigateur arrête la surveillance des éléments plus volumineux lorsque l'utilisateur a fait défiler la page ou interagi avec celle-ci.
C'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 cherche à détecter. De plus, il ne serait pas logique de prendre en compte les éléments ajoutés à la fenêtre d'affichage après une interaction de l'utilisateur, car ces éléments n'ont peut-être été chargés que à cause d'une action effectuée par l'utilisateur.
Toutefois, cela signifie que les données de champ d'une page peuvent indiquer des délais LCP plus courts, en fonction du comportement des utilisateurs sur cette page.
FID
Le FID nécessite une interaction de l'utilisateur réel
La métrique FID mesure la réactivité d'une page aux interactions des utilisateurs au moment où les utilisateurs ont effectivement choisi d'interagir avec elle.
La deuxième partie de cette phrase est essentielle, car les tests de laboratoire, même ceux qui prennent en charge le comportement des utilisateurs de scripts, ne peuvent pas prédire avec précision le moment où les utilisateurs choisiront d'interagir avec une page. Ils ne peuvent donc pas mesurer précisément le FID.
La navigation détaillée ne tient pas compte du comportement des utilisateurs
La métrique de l'atelier Temps de blocage total (TBT) permet de diagnostiquer les problèmes liés au FID, 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 tâches de rendu intensives 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 jusqu'à la fin de l'exécution du code JavaScript, le FID peut être très faible.
Le choix des utilisateurs d'interagir avec une page dépend en grande partie de son apparence interactive ou non, et cela ne peut pas être mesuré avec la fonctionnalité de test de navigation détaillée.
La fonctionnalité de navigation détaillée ne tient pas compte du délai d'appui
Si un site n'est pas optimisé pour l'affichage sur mobile, les navigateurs ajoutent un délai de 300 ms après chaque appui avant d'exécuter les gestionnaires d'événements. En effet, ils doivent déterminer si l'utilisateur essaie d'appuyer deux fois pour zoomer avant de déclencher des événements de clic ou de souris.
Ce délai est comptabilisé dans le FID d'une page, car il contribue à la latence d'entrée réelle de l'expérience utilisateur. Toutefois, comme ce délai n'est techniquement pas une tâche longue, il n'affecte pas la requête de navigation détaillée d'une page. Cela signifie qu'une page peut présenter un FID médiocre bien qu'elle présente des scores de perte de données très élevés.
Effets de l'état du cache et du cache amélioré sur le FID
Tout comme une mise en cache appropriée peut améliorer le LCP sur le terrain, elle peut également améliorer le FID.
En situation réelle, un utilisateur peut avoir déjà dans le cache le code JavaScript d'un site. Son traitement pourrait donc prendre moins de temps et réduire les délais.
Il en va de même pour les pages restaurées à partir du cache amélioré. Dans ce cas, le code JavaScript est restauré à partir de la mémoire. Le temps de traitement peut donc être faible, voire inexistant.
CLS
Effets de l'interaction de l'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 de la ligne de flottaison et pendant le chargement. Il ne s'agit toutefois que d'un sous-ensemble de ce que le CLS mesure réellement.
Dans ce champ, le CLS prend en compte tous les changements de mise en page inattendus qui se produisent tout au long de la durée de vie de la page, y compris le contenu qui change lorsque l'utilisateur fait défiler la page ou en réponse à des requêtes réseau lentes après une interaction de l'utilisateur.
Par exemple, il est assez fréquent que les pages chargent des images ou des iFrames sans dimensions de manière différée, ce qui peut entraîner des décalages de mise en page lorsque l'utilisateur fait défiler la page jusqu'à ces sections. Toutefois, ces variations ne se produisent que si l'utilisateur fait défiler la page vers le bas, ce qui n'est souvent pas pris en compte dans un test d'atelier.
Contenu personnalisé
Le contenu personnalisé, y compris les annonces ciblées et les tests A/B, a une incidence sur 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 l'atelier, une page est généralement chargée sans contenu personnalisé ou avec du contenu destiné à un "utilisateur test" générique, qui peut déclencher ou non les changements que les utilisateurs réels observent.
Étant donné que les données de champ incluent l'expérience de tous les utilisateurs, le nombre (et le degré) de décalages de mise en page rencontrés sur une page donnée dépend fortement du contenu chargé.
Effets de l'état du cache et du cache amélioré sur le CLS
Les images et les iFrames sans dimensions (comme indiqué ci-dessus) et les polices Web à chargement lent sont deux des causes les plus courantes de décalages de mise en page lors du chargement. Ces deux problèmes sont plus susceptibles d'affecter l'expérience la première fois qu'un utilisateur consulte 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 du cache amélioré, le navigateur peut généralement afficher immédiatement les images et les polices, sans attendre leur téléchargement. Cela peut entraîner des valeurs CLS inférieures à ce qu'un outil d'atelier pourrait indiquer.
Que faire lorsque les résultats sont différents ?
En règle générale, si vous disposez à la fois de données réelles et de données de laboratoire pour une page donnée, vous devez utiliser ces données pour hiérarchiser vos efforts. Étant donné que les données de terrain représentent ce que les utilisateurs réels vivent, il s'agit du moyen le plus précis de comprendre ce qui pose problème et ce qui doit être amélioré.
D'un autre côté, si vos données réelles affichent de bons scores à tous les niveaux, mais que vos données de test suggèrent qu'il reste encore des points à améliorer, il est utile de comprendre quelles autres optimisations peuvent être effectuées.
En outre, bien que les données réelles capturent les expériences utilisateur réelles, elles ne le sont que pour les utilisateurs qui peuvent charger votre site. Les données de test peuvent parfois vous aider à identifier des opportunités d'élargir l'audience de votre site et de le rendre plus accessible aux utilisateurs dont les réseaux sont plus lents ou les appareils d'entrée de gamme.
De manière générale, les données de test et les données réelles sont des éléments importants pour mesurer efficacement les performances. Elles ont toutes deux des points forts et des limites, et si vous n'en utilisez qu'une seule, vous risquez de manquer une occasion d'améliorer l'expérience de vos utilisateurs.