Pour le monitoring de vos performances, si vous faites appel aux outils Google (PageSpeed Insights ou Google Lighthouse), vous aurez certainement remarqué que pour un même indicateur, les données sont différentes. Pourquoi ? Lesquelles prioriser pour optimiser votre vitesse de chargement ? On vous explique comment vous y retrouver pour bien exploiter ces informations, et améliorer les performances et la vitesse de votre site web.
Différence entre données de terrain (Field) et données de laboratoire (Lab) : une question de méthode
Sur la page de résultats de PageSpeed Insights (dont le score repose sur Lighthouse), deux familles de données cohabitent, recueillies chacune dans des conditions différentes.
- Les données de terrain ou Field data : ces données sont collectées sur une période de 28 jours, auprès d’utilisateurs réels issus d’un panel appelé CrUX. Il s’agit de Real User Monitoring (RUM).
Google observe ici le 75ème percentile, ce qui signifie qu’en pratique, 75% des utilisateurs ont une expérience d’une qualité supérieure à ce que remonte Google dans PageSpeed Insights.
Comme elles sont collectées auprès d’utilisateurs réels, les données de terrain couvrent une très grande variété de situations : qualité et tailles d’écrans d’ordinateurs et mobiles, qualité de réseau et zones géographiques variables...
Notez que Google recommande de collecter soi-même les données réelles, car les insights seront plus actionnables par rapport au fait de s’appuyer seulement sur le panel CrUX, notamment parce que ce panel ne représente pas 100% des utilisateurs. - Les données de laboratoire, ou Lab data : pour afficher ces données, Lighthouse (qui sert de base au score PageSpeed Insights de Google) extrapole les résultats à partir d’une connexion native via un algorithme. Il s’agit de données synthétiques, ou de Synthetic Monitoring.
Avec ce mode de collecte de données, les cas de figure sont limités aux paramètres définis pour le test : un seul type de device, de réseau, et dans une zone géographique donnée.
Cette méthode est utile, par exemple, pour identifier et résoudre des bugs.
Vous vous en doutez, le fait que les méthodes de collecte soient différentes entraîne forcément des résultats différents. Comment vous y retrouver, et que faire pour améliorer votre expérience utilisateur à partir de ces KPIs ?
Focus sur les Core Web Vitals, afin de bien comprendre les raisons des différences entre Field et Lab data pour ces métriques.
Notez que fin 2021, Google a annoncé des modifications du design de l’interface de PageSpeed Insights pour faciliter la lecture et la compréhension des données.
Lighthouse / PageSpeed Insights et Largest Contentful Paint (LCP) : pourquoi les données Field et Lab sont différentes ?
Données FIeld (en haut) et Lab (en bas) :
pour les mêmes indicateurs de performance web, les résultats sont différents
en raison du contexte de collecte des données indiqués dans l’encadré grisé
L’élément LCP n’est pas le même pour tous les utilisateurs
L’élément le plus important sur une page, et identifié pour les données Lab pour évaluer le Largest Contentful Paint, n’est pas forcément le même pour vos visiteurs en conditions réelles. En effet, en faisant plusieurs fois des tests Lighthouse sur une même page, l’élément LCP sera identique. En revanche, pour des données de terrain (Field), l’élément LCP va dépendre du contexte de navigation propre à chaque visite de page.
Voici des exemples de ce qui peut faire varier l’élément LCP :
- La taille de l’écran, qui fait que tous les utilisateurs ne voient pas exactement les mêmes contenus s’afficher dans leur navigateur.
- Le fait qu’un utilisateur soit connecté ou non, et le contenu peut alors être personnalisé ou non (idem dans le cas d’un Test A/B).
- Les fonts système installées sur l’appareil de l’utilisateur, qui peuvent modifier la place que prend le texte sur une page donnée.
- Les tests pour les données Lab sont généralement effectués sur une URL “de base”. En réalité, les utilisateurs partagent souvent des URLs contenant des éléments qui font que l'élément LCP peut se trouver après la ligne de flottaison (Fragment Identifiers ou Text Fragments).
Et en pratique ? Nous l’avons vu plus tôt, pour les données Field, le LCP est calculé d'après le 75ème percentile de toutes les visites sur une page.
Ainsi, si un grand pourcentage des utilisateurs ont un élément LCP qui se charge rapidement, le score de la page ne sera pas affecté par ceux dont l’élément LCP se charge lentement - à condition que moins de 25% des visiteurs soient concernés.
A l’inverse, un élément tel qu’un bloc de texte peut être identifié comme LCP sur un écran de petite taille pour des données Lab, tandis que l’image principale est rendue hors écran. Cependant, vos données de terrain (Field) peuvent inclure principalement des utilisateurs dotés d’écrans plus grands, et pour eux, ce sera donc cette image lente à charger qui sera leur élément LCP - avec l’impact que ça implique pour votre score.
L’impact de l’état du cache sur le LCP
Les données Lab correspondent généralement à une page avec un cache "froid", alors que les données Field peuvent correspondre à des utilisateurs pour qui des données sont déjà mises en cache, et dont la vitesse de chargement sera meilleure.
Certains outils de Synthetic Monitoring permettent de tester plusieurs fois une même page pour simuler l’expérience d’utilisateurs dans le cadre d’une “revisite”, toutefois, il n’est pas possible de connaître le pourcentage de ces visiteurs pour qui des données sont déjà mises en cache.
Ainsi, le LCP dans les données Field, pour un site avec une stratégie de cache efficace, peut être bien meilleur que celui indiqué dans les données Lab.
L’impact d’AMP ou Signed Exchange sur le LCP
Les visiteurs de sites qui utilisent AMP ou Signed Exchange (SXG) peuvent expérimenter une vitesse de chargement bien meilleure que les autres.
Outre le préchargement inter-origine, ces sites peuvent précharger du contenu pour les pages suivantes, ce qui peut contribuer à optimiser le Largest Contentful Paint.
Mais les outils Lab ne peuvent pas simuler les gains de performance obtenus dans ce contexte, et même s'ils étaient en mesure de le faire, ils ne pourraient pas connaître le pourcentage de trafic concerné.
L’impact du bfcache sur le LCP
Pour des pages servies à partir d’un cache back/forward (ou bfcache), le chargement est quasi instantané. Ces données comptent dans vos résultats de tests Field, mais pas pour les données Lab.
L’impact des interactions d’utilisateurs réels sur le LCP
Le LCP permet d’identifier le temps nécessaire pour l’affichage du plus grand élément (texte ou image), mais il peut changer au cours du chargement de la page, notamment si un nouveau contenu est ajouté dynamiquement dans le viewport.
Pour des données Lab, le navigateur attend que la page soit chargée totalement pour identifier l’élément LCP ; mais pour des données Field, la détection du LCP par le navigateur cesse dès que l'utilisateur fait défiler la page ou interagit.
Ce principe de calcul du LCP est logique, puisque d’une part, un utilisateur commence à interagir avec une page à partir du moment où elle lui semble chargée (et non une fois qu’elle est chargée entièrement) ; et d’autre part, prendre en compte un élément LCP qui s’afficherait uniquement suite à une interaction d’un utilisateur ne serait pas pertinent.
De ce fait, les données Field indiquent potentiellement un LCP plus rapide en fonction du comportement des utilisateurs réels sur une page.
PageSpeed Insights / Lighthouse et Cumulative Layout Shift (CLS) : pourquoi les données Field et Lab sont différentes ?
L’impact des interactions d’utilisateurs réels sur le CLS
Pour des données Lab dans PageSpeed Insights, le Cumulative Layout Shift ne tient compte que des changements de mise en page au-dessus de la ligne de flottaison et pendant le chargement, sachant que ce n’est qu'un sous-ensemble de ce que le CLS mesure réellement.
Pour des données Field, auprès d'utilisateurs réels, le CLS prend en compte tous les changements de mise en page inattendus, tout au long de sa durée de vie (notamment si des éléments se déplacent suite à une action de scroll sur du contenu, par exemple).
Prenons le cas du lazyloading d’images ou des iframes sans dimensions : ils peuvent générer des changements de mise en page suite à un scroll de l’utilisateur. Ce changement n’intervient que si l'utilisateur fait défiler la page vers le bas, et ce phénomène n’est généralement pas détectable dans les données Lab (il n’y a pas d’interaction utilisateur dans ce cas).
L’impact du contenu personnalisé sur le CLS
La personnalisation de contenu (y compris les publicités ciblées, les tests A/B…) impacte le chargement des éléments sur une page, et la façon dont ils se chargent.
En effet, le contenu personnalisé peut entraîner des changements de mise en page car il est chargé après le contenu principal, et souvent inséré dynamiquement.
Il faut savoir que les données Lab correspondent généralement aux performances d’une page sans contenu personnalisé, pour un utilisateur lambda.
Quant aux données Field, elles sont fortement tributaires de la quantité et du degré de décalage de mise en page observés auprès des utilisateurs réels du site.
L’impact de l'état de la mémoire cache et du bfcache sur le CLS
Comme nous l’avons évoqué, les images et les iframes sans dimensions font partie des causes les plus fréquentes de décalage de mise en page. Il faut aussi compter les polices web qui se chargent lentement (que vous pouvez optimiser très facilement avec Fasterize).
Ces phénomènes peuvent affecter l’expérience utilisateur lors de la première visite d’un site, lorsque son cache est vide.
En revanche, si les ressources d’une page web sont déjà présentes dans le cache, ou dans le cas d’une page servie depuis un bfcache, les images et les fonts peuvent s’afficher instantanément.
Ainsi, le score CLS peut être meilleur dans les données Field par rapport aux données Lab.
Pourquoi le First Input Delay (FID) ne peut être mesuré qu’à partir d’utilisateurs réels, et pourquoi il est différent du TBT
Pour mesurer le FID, il faut une interaction d’un utilisateur
Le First Input Delay évalue la réactivité d'une page suite aux interactions des utilisateurs, au moment où ils interagissent réellement.
Or, les données Lab ne permettent pas de prédire quand un utilisateur décide d'interagir avec une page, et ne permettent donc pas mesurer avec précision le FID.
D’autres métriques permettent d’évaluer l’interactivité avec du Synthetic Monitoring : le Total Blocking Time (TBT), et le Time To Interactive (TTI).
Les données synthétiques ne tiennent pas compte du comportement de l’utilisateur
Le Total Blocking Time (TBT) et le Time To Interactive (TTI) aident à détecter les problèmes de FID. En effet, ces mesures permettent d’identifier le degré de blocage du fil principal (Main Thread) pendant le chargement d’une page web.
Si un utilisateur tente d’interagir avec une page qui contient beaucoup de JavaScript synchrone, par exemple, il y a plus de chances pour que le fil principal soit bloqué au moment où il décide d’interagir.
En revanche, si un utilisateur attend que le JavaScript ait fini de s’exécuter pour interagir, le FID pourra alors être très faible.
En somme, le moment où l’utilisateur choisit d’interagir avec une page est déterminant pour le FID, et ce moment dépend beaucoup de l’aspect interactif ou non de la page (ce que le TBT et le TTI ne peuvent pas évaluer).
Il faut aussi savoir que ni le TBT, ni le TTI ne tiennent compte du délai suite à une interaction sur un écran mobile, appelé Tap Delay.
Ainsi, pour une page qui n'est pas optimisée pour l'affichage sur mobile, le navigateur ajoute un délai de 300 ms après toute pression avant d'exécuter les gestionnaires d'événements.
Pour quelle raison ? Parce que le navigateur doit déterminer si l’utilisateur veut zoomer à l’aide d’un double tapotement avant de déclencher les événements “souris” ou “clic”. Aussi, pour éviter le problème de Tap Delay sur une page, il est recommandé de toujours spécifier un viewport mobile.
Ce Tap Delay compte pour le FID car il contribue au phénomène de latence expérimenté par des utilisateurs réels. Mais comme ce n’est pas une Long Task, le TBT et le TTI ne sont pas impactés
En conséquence, une page peut avoir un mauvais FID malgré de très bons scores TBT et TTI.
L’impact de l'état de la mémoire cache et du bfcache sur le FID
Une bonne stratégie de cache permet d’améliorer le FID, au même titre que le LCP.
En conditions réelles de navigation, le JavaScript d’une page web peut être mis en cache, et son traitement prend alors moins de temps, ce qui améliore la vitesse de chargement.
C’est la même chose pour les pages servies à partir du bfcache, car le JavaScript est alors restauré à partir de la mémoire. Le temps de traitement peut alors être très faible, voire nul.
Maintenant que nous avons vu les différentes raisons pour lesquelles les données Field et Lab peuvent être différentes pour le LCP, le CLS et le FID, vous vous demandez certainement comment choisir pour mesurer et optimiser votre vitesse de chargement !
Vitesse de chargement et optimisation des Core Web Vitals : comment choisir entre les données Field et Lab ?
Ne faisons pas durer le suspense plus longtemps : priorité aux données de terrain !
Vous avez intérêt à observer les données Field pour prioriser vos efforts pour l’optimisation de l’expérience utilisateur.
En effet, ces données traduisent l’expérience de vos utilisateurs réels, ce qui en fait l’outil d’aide à la décision le plus approprié pour améliorer votre vitesse de chargement, votre expérience utilisateur, et vos taux de conversion.
Même si vos données Field sont satisfaisantes, ne délaissez pas les données Lab pour autant : elles peuvent indiquer qu’il reste des améliorations à apporter, et vous avez tout intérêt à creuser le sujet pour aller toujours plus loin dans l’optimisation de vos performances.
Nos experts sont à votre écoute pour vous aider à décrypter le sujet, et vous montrer comment notre solution vous aide à automatiser toutes les optimisations webperf pour transformer votre site en véritable bolide !
Il peut suffire de seulement quelques millisecondes pour constater un impact sur votre CA.
Eh oui ! Google a noté que rien qu’avec 0,1 seconde de chargement en moins, les conversions peuvent monter de 8%. Alors, prêts à passer à la vitesse supérieure ?
Allez encore plus loin sur les Core Web Vitals,
découvrez ce qu’ils mesurent exactement,
et comment les améliorer avec des techniques et des outils de pros :
