Suivi des utilisateurs réels : comprendre la vitesse d'un site web en conditions réelles et en laboratoire

Utilisateurs réels et tests en laboratoire

Surveillance des utilisateurs réels (RUM) mesure le fonctionnement d'un site web lors de visites réelles. Une consultation sur un smartphone plus ancien via un réseau mobile peut différer considérablement d'une visite sur un ordinateur de bureau doté d'une connexion rapide. Les pages consultées et les interactions ont également une incidence sur le tableau observé.

A Test en laboratoire analysera en revanche un appel défini dans des conditions contrôlées. Le type d'appareil, les conditions réseau et le déroulement du test peuvent être définis pour une analyse. Cela permet de reproduire plus facilement un comportement anormal et de vérifier les modifications éventuelles dans des conditions comparables.

Ces deux points de vue apportent des réponses à des questions différentes : les données de terrain peuvent montrer que les pages de produits sur mobile s'affichent souvent lentement. Elles ne permettent toutefois pas de déterminer si, par exemple, l'image du produit, le chemin de rendu ou une réponse lente du document en sont la cause. Pour identifier la cause, il faut recourir à des diagnostics supplémentaires et à des hypothèses vérifiables.

PageSpeed Insights combine ces deux perspectives : il compare les données de terrain issues du Chrome User Experience Report aux diagnostics en laboratoire basés sur Lighthouse. Les résultats ne sont pas nécessairement identiques, car les visites réelles se déroulent dans des conditions et selon des parcours d'utilisation variés, tandis que le laboratoire examine un scénario de test défini.

Le RUM ne remplace donc pas le laboratoire. À l'inverse, un seul test en laboratoire ne permet pas de déterminer la fréquence à laquelle un problème se produit chez les visiteurs réels. Avant une mise en ligne ou dans le cas d'un site peu fréquenté, il se peut en outre que l'on ne dispose pas de données de terrain suffisantes ; sans visites réelles, il n'y a tout simplement pas de mesures RUM propres au site.

Voici comment sont obtenues les valeurs mesurées par RUM

Une mesure personnalisée repose sur trois éléments : un suivi dans le navigateur, un récepteur pour les valeurs transmises et une analyse. Vous devez d'abord définir les pages et les groupes de visiteurs que vous souhaitez étudier, ainsi que la manière dont les données seront protégées. Ce n'est qu'à partir de valeurs individuelles regroupées de manière pertinente que l'on peut établir une base décisionnelle.

Les navigateurs proposent à cet effet différentes interfaces de performance. Synchronisation de la navigation décrit les moments clés liés à l'accès au document, comme la réponse à la requête de document. Resource Timing fournit des informations temporelles sur chaque ressource chargée, par exemple les images ou les scripts. Cela permet de cerner plus précisément les différentes étapes d'un processus de chargement.

A PerformanceObserver surveille les entrées de performance prises en charge dès qu'elles sont disponibles. Pour les Core Web Vitals, la bibliothèque peut web-vitals se charger du calcul et de la transmission des données. Les données et indicateurs disponibles dépendent notamment du navigateur utilisé ; un script de mesure ne recense donc pas automatiquement l'intégralité de chaque visite.

Toutes les valeurs ne sont pas générées directement lors du chargement. Pour l'INP, par exemple, une interaction appropriée doit avoir lieu : une personne qui se contente de lire une page avant de la quitter ne génère peut-être aucune valeur. Une valeur manquante n'est donc ni égale à zéro, ni la preuve d'une réaction rapide.

Un service RUM peut fournir les fonctionnalités de collecte, de réception et d'analyse sous forme de solution complète. Si vous développez vous-même une solution, vous devrez en outre vous charger de l'exploitation, du stockage et de l'assurance qualité. Cela implique notamment de traiter correctement les messages répétés au cours du cycle de vie d'une page, au lieu de compter chaque message comme une visite distincte sans le vérifier.

Bien interpréter les Core Web Vitals

Le Core Web Vitals décrivent trois aspects différents de l'expérience utilisateur. Le Largest Contentful Paint (LCP) mesure le moment où le plus grand élément de contenu pertinent devient visible. Sur une page produit, il peut s'agir, par exemple, d'une grande image du produit : si celle-ci s'affiche tardivement, la page peut donner l'impression de ne pas être entièrement chargée, même si la navigation est visible depuis le début.

L'indicateur « Interaction to Next Paint » (INP) mesure le délai entre une interaction et la prochaine mise à jour visible. Si un filtre de produit ne réagit de manière perceptible qu’après un clic, l’INP peut signaler ce problème. Le Cumulative Layout Shift (CLS), quant à lui, décrit les décalages inattendus du contenu visible, par exemple lorsqu’un élément affiché ultérieurement déplace un bouton.

Dans l'évaluation de PageSpeed Insights, un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1 sont considérés comme bons. Le CLS est une valeur sans unité. Ces seuils s'appliquent à chaque indicateur et ne doivent pas être confondus avec la durée d'un chargement de page individuel.

L'élément déterminant pour l'évaluation du terrain est le 75e centile (p75) : Au moins environ 75 % des expériences prises en compte ne dépassent pas la valeur correspondante. En revanche, une bonne moyenne peut à elle seule masquer le fait qu’une part considérable des visites est lente. Considérez séparément les appareils mobiles et les ordinateurs de bureau afin que les différences entre les groupes d’appareils restent visibles.

Le « Time to First Byte » (TTFB) vient compléter ces indicateurs lorsqu'on cherche à identifier une réponse lente à une requête de document. Cette valeur ne correspond toutefois pas uniquement au temps de traitement du serveur : le réseau et les autres étapes jusqu'à la réception du premier octet de réponse jouent également un rôle. Le « Navigation Timing » et, le cas échéant, les données de « Server Timing » fournies permettent d'analyser plus précisément les étapes concernées.

CrUX, son propre RUM et son laboratoire

Pour commencer, tu n'as pas besoin de mettre immédiatement en place ton propre système de mesure. PageSpeed Insights combine les données de terrain provenant du Rapport sur l'expérience utilisateur de Chrome (CrUX) avec un diagnostic en laboratoire Lighthouse. Ces deux perspectives apportent des réponses à des questions différentes : l'une décrit les expériences recueillies, tandis que l'autre analyse une page dans des conditions contrôlées.

Les données de terrain CrUX dans PageSpeed Insights couvrent une période rétrospective de 28 jours. Si les données relatives à une URL spécifique sont insuffisantes, le rapport peut alors afficher les données de l'origine à la place. Celles-ci concernent l'origine du site web correspondant et ne reflètent pas exactement l'expérience sur la page saisie. Veillez donc à bien vérifier à quel niveau le rapport se situe réellement.

CrUX ne prend en compte que les utilisateurs de Chrome qui remplissent les conditions requises ; les autres navigateurs et les utilisateurs non éligibles ne sont pas pris en compte. Sur un site web de petite taille ou non public, les données CrUX peuvent faire défaut. Une collecte propre, conforme sur le plan juridique et technique, peut néanmoins fournir des informations utiles, mais reste statistiquement limitée si le nombre de visites est faible.

La surveillance synthétique répète des tests prédéfinis, même lorsqu'aucun utilisateur ne se trouve sur le site web. Elle permet d'observer régulièrement un processus dans des conditions similaires. Seule une mesure sur le terrain permet de déterminer si les utilisateurs bénéficient de la même expérience lorsqu'ils utilisent d'autres appareils ou se connectent à d'autres réseaux ; un seul test synthétique ne saurait se substituer à cette analyse.

Pour faire ton choix, il faut donc te poser la question à laquelle tu souhaites répondre : un rapport public est rapidement accessible, tandis qu’un système propre à l’entreprise permet une collecte plus ciblée. Un service peut alléger la charge de travail opérationnel, tandis que les analyses en laboratoire et les essais synthétiques permettent de mener des études contrôlées. Cependant, même un service nécessite une sélection réfléchie des données et des groupes d’évaluation.

Bien préparer ses propres mesures

Commencez par définir une question précise, par exemple si les pages de produits sur mobile présentent plus souvent un LCP élevé que d'autres types de pages. Déterminez ensuite quelles pages et quelles catégories d'appareils vous souhaitez distinguer, quels indicateurs sont nécessaires à cet effet et pendant combien de temps vous souhaitez collecter des données. Ce n'est qu'ensuite que vous choisirez le script de mesure, le destinataire et le mode d'analyse.

Pour commencer sur le plan technique, tu peux utiliser la bibliothèque web-vitals l'intégrer localement dans un projet de navigateur et visualiser le résultat dans les outils de développement. Le code JavaScript suivant utilise la version 6.2.3 du paquet publiée. Il suppose que cette version est installée dans le projet et que la compilation gère les importations de modules. Cet exemple n'envoie aucune donnée à un serveur et n'active pas de mesure distincte des navigations logicielles.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

La sortie en ligne de commande est un moyen de vérifier l'intégration, et non une indication de la vitesse de vos visiteurs. Ouvrez la page du projet et interagissez, par exemple, avec un filtre. Une valeur INP suppose une interaction appropriée et n'apparaît pas nécessairement immédiatement ; sans interaction adéquate, elle peut même être totalement absente. La prise en charge par le navigateur et le cycle de vie de la page influencent également ce résultat.

Prévois, en vue d'une analyse ultérieure, le Cycle de vie d'une page Remarque : les événements peuvent être enregistrés plusieurs fois, par exemple lorsqu'une page est masquée puis réaffichée. Ne comptez pas systématiquement ces événements comme des visites distinctes. La bibliothèque fournit des identifiants de métrique permettant d'associer les événements à une même métrique.

Une restauration à partir du cache « Back/Forward » nécessite également un traitement spécifique. Elle peut déclencher un nouveau message de métrique, même si le document provient du cache. Définissez comment vous distinguez ces récupérations des navigations habituelles dans votre rapport, et consultez les consignes spécifiques de la bibliothèque avant de mettre en place un enregistrement en production.

Analyser les valeurs mesurées par segment

Une valeur globale pour la boutique en ligne peut masquer le fait que les pages de produits sur mobile sont justement plus lentes. Il convient donc de ventiler les données de mesure au moins par type de page et par catégorie d'appareils, et d'examiner chaque indicateur sur une période donnée. Vous pourrez ainsi, par exemple, comparer les pages de produits sur mobile aux pages de catégories sur mobile, au lieu de mélanger sans vous en rendre compte des situations d'utilisation différentes.

Pour chaque segment, c'est le 75e centile plus révélateur qu'une simple moyenne : il indique la valeur que ne dépassent pas au moins environ 75 % des expériences prises en compte. Une moyenne faible peut en revanche masquer le fait qu'un groupe pertinent doit attendre longtemps. Ne comparez le p75 qu'entre des indicateurs identiques et dans la même unité.

Le nombre de valeurs valides fait directement partie du résultat. Si un segment ne comprend que quelques mesures, certaines données isolées peuvent fortement influencer le centile ; une variation ne signifie donc pas nécessairement qu'il s'agit d'un problème général. Si nécessaire, choisis une période plus longue ou regroupe des pages thématiquement similaires, sans pour autant compromettre la comparabilité des résultats.

Un INP manquant n'est pas un INP rapide et ne doit pas être pris en compte dans la répartition comme une valeur nulle. Indiquez plutôt séparément le nombre de valeurs INP valides. Lorsque de nombreuses visites ne fournissent pas d'interaction appropriée, l'analyse de l'INP ne décrit que les expériences d'interaction enregistrées et ne couvre pas automatiquement toutes les visites de la page.

Regroupez correctement les messages répétés en fonction de l'ID de métrique, au lieu de traiter chaque réponse comme une nouvelle observation indépendante. Documentez également la manière dont les restaurations à partir du cache « back/forward » sont comptabilisées. Cela permet de vérifier quelles observations sont effectivement incluses dans le p75 et dans le nombre indiqué.

Du problème sur le terrain au diagnostic

Si les données de terrain indiquent des pages de produits qui se chargent lentement sur mobile, commence par cerner le segment concerné : le mauvais LCP affecte-t-il de nombreux produits ou seulement un type de page ? Vérifie également la période concernée et le nombre de valeurs valides. Tu obtiendras ainsi un point de départ pour ton analyse, mais pas encore de preuve permettant d'identifier l'élément à l'origine du ralentissement.

Placez ensuite dans le Test en laboratoire Recréez des conditions aussi proches que possible, par exemple avec une configuration d'appareil mobile et un débit réseau limité. Identifiez quel élément apparaît comme LCP et à quel moment il est chargé et affiché. Une grande image de produit, une requête d’image tardive ou un chemin de rendu bloqué sont des hypothèses possibles que vous devez vérifier à l’aide du diagnostic.

Si tu constates que des images sont transmises, tu peux examiner leur taille, leurs formats et leur mise à disposition. Un Réseau de diffusion de contenu C'est une mesure envisageable, mais cela ne garantit pas une amélioration du LCP. En revanche, si la réponse du document indique un goulot d'étranglement, un complément Test de performances des serveurs pour les charges de travail PHP, d'étudier l'application dans des conditions définies.

Dans le cas d'un filtre de produit différé, c'est l'interaction qui prime sur le processus de chargement. Simulez un clic sur le filtre et vérifiez les opérations nécessaires jusqu'à ce que la mise à jour soit visible. Lorsque le navigateur le prend en charge, il est possible de Images d'animation longues Elles fournissent des indications sur les mises à jour de rendu longues et les scripts impliqués ; elles n'expliquent pas automatiquement chaque interaction lente.

Mettez en œuvre une modification ciblée, puis observez à nouveau le même groupe de pages en conditions réelles. Un meilleur résultat en laboratoire ne reflète dans un premier temps que l'effet observé dans les conditions de test choisies. Seule l'évaluation ultérieure en conditions réelles permettra de déterminer si les expériences enregistrées des visiteurs réels ont également évolué.

Qualité des données et protection des données dans l'entreprise

Avant la mise en production, détermine quelles données de mesure sont nécessaires pour répondre à ta problématique et qui les traitera. La planification doit inclure une transmission sécurisée vers le destinataire, des restrictions d’accès, une durée de conservation limitée et une procédure de suppression. Vérifie les questions relatives à la protection des données et au consentement pour la mise en œuvre concrète, ainsi que les règles applicables d’un point de vue technique, plutôt que de te contenter d’une autorisation générale.

Lors de la Minimisation des données Il est utile de se pencher sur les champs de diagnostic : les URL complètes peuvent contenir des informations sensibles dans les paramètres de requête ; les sélecteurs DOM peuvent également révéler des détails sur le contenu des pages ou les saisies. Dans la mesure du possible, identifiez un type de page général et quelques attributs sélectionnés de manière ciblée. Vérifie également quelles données supplémentaires un service intégré collecte ou stocke.

Les valeurs mesurées ne sont pas toujours disponibles immédiatement. La bibliothèque web-vitals peut générer plusieurs fois des retours d'information au cours du cycle de vie d'une page ; un message ultérieur ne doit donc pas être considéré d'emblée comme une nouvelle visite indépendante. Prévoyez la manière dont les notifications associées seront traitées et dont les restaurations à partir du cache « Back/Forward » seront gérées.

Pour les petits paquets de données de diagnostic, la transmission peut s'effectuer via sendBeacon lors de l'événement visibilitychange être adapté. Cela améliore la possibilité de déclencher la transmission de données lors de la mise en cache d'une page, mais ne garantit pas la livraison. Le destinataire doit en outre accepter les données en toute sécurité et les traiter de manière à ce que les messages répétés ne faussent pas l'analyse sans que cela soit remarqué.

Enfin, tiens compte de la lacunes dans la collecte des données: Les scripts bloqués, la non-prise en charge par certains navigateurs ou les transmissions perdues peuvent entraîner l'absence de certaines visites. Évaluez un taux de perte estimé en tenant compte du mode de collecte. Les mesures obtenues décrivent le groupe observé et ne reflètent pas nécessairement l'ensemble des visiteurs de manière égale.

Évaluer les changements et choisir une méthode

Pour effectuer une comparaison après un déploiement, tu dois définir au préalable les types de pages, les classes d'appareils et les périodes à prendre en compte. Pour chaque indicateur, compare le 75e centile et le nombre de valeurs valides avant et après le changement. Des plages de temps de durée similaire facilitent l'interprétation ; toutefois, cela ne garantit pas automatiquement l'obtention d'échantillons suffisamment comparables.

Tenez compte d'une évolution de la composition de l'audience. Si, après un déploiement, le nombre d'utilisateurs disposant d'une connexion mobile lente augmente, la performance globale peut se détériorer, même si le changement en lui-même n'entraîne pas de ralentissement. L'utilisation saisonnière ou d'autres changements simultanés compliquent également l'attribution. Un lien temporel reste donc une hypothèse, et non une Preuve de causalité.

CrUX et votre propre RUM ne fournissent pas nécessairement les mêmes résultats : ils peuvent couvrir des groupes d'utilisateurs, des plages horaires et des conditions de collecte différents. Dans le cas du CLS, il faut également noter que CrUX prend en compte la contribution des cadres intégrés à l'expérience de la page parente. Une mesure JavaScript dans le document principal ne capture pas toujours entièrement ces contributions. Il convient donc de comparer d'abord les bases de mesure avant de considérer un écart comme une erreur.

Dans le cas d'une application monopage, vous devez déterminer si vous souhaitez analyser les navigations entre documents ou les changements de route internes. Pour la collecte séparée de Navigation douce Prend en charge Web Vitals à partir de la version 6, sous réserve d'une prise en charge adéquate par le navigateur, l'option reportSoftNavs: true. Elle doit être définie dans les callbacks de métrique correspondants. L'exemple de console précédent, qui ne comporte pas cette option, n'active pas de mesure séparée des itinéraires.

Lorsque la détection de la navigation logicielle est activée, les valeurs CLS et INP sont réinitialisées pour la nouvelle navigation et prises en compte séparément ; les valeurs de la navigation précédente sont clôturées lors du changement d'itinéraire. Il ne faut pas comparer ces valeurs, dont la période de référence diffère, avec les mesures à l'échelle du document sans les vérifier au préalable. Sans prise en charge appropriée par le navigateur, cette option n'entraîne pas de mesure distincte de l'itinéraire.

Pour choisir un service RUM, tu dois vérifier, outre la prise en charge des navigateurs, si les groupes de pages et les classes d'appareils dont tu as besoin peuvent être analysés. Renseigne-toi sur les méthodes d'échantillonnage, le traitement des données, leur conservation et les possibilités d'exportation. Il est tout aussi important de déterminer l'impact que le script de mesure lui-même peut avoir sur la page et si sa collecte peut être limitée à ce qui est nécessaire pour répondre à ta problématique.