Découvrez les raisons pour lesquelles les données RUM peuvent afficher différents chiffres des Core Web Vitals issus de CrUX.
Le rapport d'expérience utilisateur Chrome fournit des métriques sur l'expérience d'utilisateurs réels de Chrome sur des destinations populaires sur le Web. Chrome collecte automatiquement ces données auprès des utilisateurs qui l'ont activée. Elles sont mises à disposition en fonction des critères d'éligibilité au CrUX.
Les données CrUX sont donc disponibles pour des millions de sites Web. De nombreux propriétaires de sites n'avaient pas accès aux données réelles auparavant, et CrUX a permis à de nombreux sites de constater l'intérêt de cette approche pour la première fois. En tant qu'ensemble de données public, CrUX peut également être utilisé pour l'analyse concurrentielle et l'analyse comparative des métriques d'expérience utilisateur.
Real User Monitoring (RUM) est semblable à CrUX, à la différence près que Chrome ne collecte pas automatiquement les métriques d'expérience utilisateur. Toutefois, du code est inclus sur les sites Web pour effectuer cette collecte et le transmettre à un fournisseur de RUM ou à une solution d'analyse pour une analyse plus approfondie.
Les deux solutions mesurant les métriques d'expérience utilisateur, il est naturel de supposer qu'elles devraient être équivalentes. Ces différences peuvent prêter à confusion. Ce guide explique pourquoi cela peut se produire et propose des suggestions sur la marche à suivre lorsque les chiffres ne correspondent pas.
Avantages de l'ajout d'une solution RUM à CrUX
CrUX est un outil formidable qui permet d'obtenir une vue cohérente entre les sites. En tant qu'ensemble de données officiel du programme Core Web Vitals, les sites voudront sans doute garder un œil sur les données qu'il contient. L'objectif de CrUX est de fournir une vue d'ensemble pertinente d'un point de vue statistique sur des millions de sites Web, afin de pouvoir effectuer des comparaisons croisées.
Toutefois, si vous souhaitez en savoir plus sur pourquoi les données révèlent les chiffres qu'elles sont, investir dans une solution RUM complète en complément de CrUX vous permet d'accéder à des informations plus détaillées que celles qui peuvent être mises à disposition dans un ensemble de données publiquement interrogeable. Cela peut vous aider à expliquer et à améliorer vos métriques de plusieurs façons.
Analyse plus approfondie pour examiner les problèmes
CrUX permet souvent d'identifier si un problème est survenu sur votre site, mais pas nécessairement sa position ni sa raison. Les solutions RUM, qu'elles aient été développées en interne par le biais de la bibliothèque Web-Vitals ou via certains des nombreux produits commerciaux, peuvent aider à combler cette lacune.
L'utilisation d'une solution RUM vous permet d'accéder à des données beaucoup plus détaillées pour toutes vos pages et dans tous les navigateurs. Il vous permet également d'examiner ces données à la manière de CrUX, ce qui vous permet d'analyser en détail les zones problématiques du site. Sont-elles affectées par un segment particulier d'utilisateurs ? Ou les utilisateurs qui effectuent certaines actions ? À quelle date précise le problème a-t-il commencé ? Il est beaucoup plus facile de répondre à ce type de questions grâce aux données supplémentaires qu'un outil RUM peut fournir.
Corrélation avec d’autres métriques commerciales
Le RUM vous permet également de comparer directement vos métriques de performances Web à n'importe quelle métrique métier. Vous pouvez ainsi déterminer la valeur d'un investissement dans les performances et identifier les autres performances à prioriser. Nous disposons de nombreuses études de cas montrant des entreprises qui établissent cette corrélation, comme Farfetch ou The Economic Times.
Collecter d'autres données de performances
Une solution RUM permet de collecter d'autres métriques personnalisées, directement liées à votre entreprise. La métrique Time to first Tweet de Twitter est l'un des exemples les plus connus. Ces mesures spécifiques au site peuvent ensuite être mises en corrélation avec les améliorations Core Web Vitals et les métriques commerciales.
Différences entre deux ensembles de données de champs
Un homme avec une montre sait l'heure. Un homme avec deux montres n'est jamais sûr.
Loi de Segal
Lorsque vous avez deux sources de données, il peut souvent être déroutant et frustrant de savoir pourquoi elles diffèrent. Tout comme il est important de comprendre la différence entre les métriques de test et de champ, il peut y avoir des différences entre deux sources de données de champ. Bien que les données soient les mêmes dans un monde idéal, il existe de nombreuses raisons pour lesquelles elles peuvent différer.
Données de test et données réelles
Commencez par vérifier si vous consultez des métriques de laboratoire (synthétique) ou des métriques de champ (RUM). Bien qu'il soit naturel de supposer que les produits RUM ne prennent en compte que les données réelles, beaucoup proposent également un composant de laboratoire.
Les données de laboratoire sont incroyablement utiles, précisément en raison des conditions fixes dans lesquelles elles se mesurent. Vous pouvez l'utiliser pour surveiller les modifications ou les régressions inattendues dans un environnement de production sans être confronté au bruit généré par l'évolution du remplissage des champs. Toutefois, les données de test peuvent ne pas être représentatives de l'expérience utilisateur réelle, et les métriques de terrain peuvent donc afficher des résultats très différents.
Populations
Les ensembles de données utilisés par les solutions CrUX et RUM peuvent être différents, car la mesure des visites de pages diffère selon les navigateurs, utilisateurs, sites et appareils concernés.
Navigateurs inclus
Le rapport d'expérience utilisateur Chrome, comme son nom l'indique, est uniquement disponible dans Chrome. Bien que de nombreux navigateurs basés sur Chromium (Edge, Opera et Brave, pour n'en citer que quelques-uns) acceptent également les mêmes métriques que Chrome, étant donné le codebase partagé, seuls les utilisateurs de Chrome envoient des données dans CrUX. Cette restriction signifie également que les utilisateurs de Chrome sous iOS ne sont pas inclus, car ils utilisent le moteur de navigateur Webkit sous-jacent. Elles ne sont pas non plus comptabilisées comme des classes "Chrome". Les données de ces utilisateurs ne sont donc pas incluses, contrairement aux onglets personnalisés Chrome.
Chrome est l'un des navigateurs les plus populaires au monde, et offre donc probablement une représentation étendue des performances de votre site dans la plupart des cas. Toutefois, mesurer ce navigateur ne permet en aucun cas de mesurer tous vos utilisateurs. Cela peut expliquer l'une des principales différences entre RUM et CrUX. Cela est particulièrement vrai pour les techniques de performance qui s'appuient sur des API ou des formats d'image disponibles uniquement dans Chrome, par exemple.
L'absence de données iOS peut également donner lieu à des biais. Par exemple, les utilisateurs iOS utilisent généralement des appareils plus performants ou viennent d'un plus grand nombre de pays disposant d'une meilleure infrastructure réseau. Inclure ces personnes peut également entraîner des métriques de performances globales élevées. En revanche, si vous les excluez, comme le fait l'expérience utilisateur Chrome, les données risquent d'être faussées pour les utilisateurs les moins actifs du site (exemple d'étude de cas). En général, les utilisateurs d'Android couvrent un éventail plus large d'appareils et de fonctionnalités, et couvrent un plus grand nombre de marchés.
Les solutions RUM peuvent obtenir des données pour des navigateurs autres que Chrome, et en particulier des navigateurs basés sur Chromium, qui intègrent souvent les mêmes métriques (comme les Core Web Vitals). Les navigateurs qui ne sont pas basés sur Chromium sont également mesurés par les solutions RUM, mais les métriques peuvent être plus limitées. Par exemple, Largest Contentful Paint (LCP) et Cumulative Layout Shift (CLS) ne sont actuellement disponibles que dans les navigateurs basés sur Chromium, et certaines autres métriques peuvent être mesurées très différemment (voir plus tard).
Utilisateurs ayant activé la fonctionnalité
En plus d'être limité aux utilisateurs de Chrome, l'expérience CrUX est davantage limitée en ne mesurant qu'un sous-ensemble d'utilisateurs de Chrome qui ont accepté de partager des données CrUX lors de l'installation du navigateur.
De plus, les fournisseurs de rUM ne s'intéressent qu'à un sous-ensemble d'utilisateurs, généralement en raison d'invites de bannières de cookies (qui demandent aux utilisateurs d'activer la collecte des données RUM) ou de bloqueurs de suivi. Cela peut avoir une incidence négative sur certains chargements de page initiaux si la confirmation n'est pas donnée avant la deuxième page ou la suivante, lorsque certains éléments du site ont déjà été mis en cache à partir des pages précédentes. Si cela se produit fréquemment, les métriques peuvent sembler plus favorables dans le RUM qu'en réalité si les chargements de page initiaux plus lents sont exclus dans un nombre suffisant de cas.
Sites inclus
L'expérience utilisateur Chrome ne concerne que les rapports sur les sites Web publics. D'autres critères d'éligibilité peuvent donc empêcher la journalisation des données dans CrUX. Le plus notable de ces critères est que le site web doit être accessible publiquement et suffisamment populaire pour garantir une taille d'échantillon minimale permettant de tirer des conclusions significatives. Dans la plupart des cas, aucune donnée ne sera alors disponible dans CrUX. Cette différence est moins complexe que les données disponibles, mais elle est différente, mais elle explique pourquoi cela se produit.
Toutefois, si certaines pages d'un site sont marquées comme indexables, mais que d'autres ne le sont pas, il se peut que seul un sous-ensemble d'URL s'affiche dans CrUX. Si l'origine est accessible au public, toutes les pages vues qu'elle contient seront incluses dans les données au niveau de l'origine, mais il est possible que les données au niveau de l'URL ne soient pas disponibles.
Appareils
CrUX segmente les données par mobile, ordinateur et tablette. Toutefois, de nombreux outils se concentrent sur les deux premiers et n'affichent pas toujours les données des tablettes, ou peuvent les inclure dans les mobiles ou les ordinateurs. Les caractéristiques de performances sur mobile et sur ordinateur peuvent être très différentes, tant en termes de contenu diffusé que de capacités des appareils qui les visualisent.
Les données RUM permettent de segmenter le trafic de la même manière, mais affichent souvent des données consolidées par défaut. RUM peut uniquement autoriser la segmentation par type d'appareil (par exemple, mobile) ou par navigateur (par exemple, Chrome), mais pas les deux afin de n'afficher que le trafic Chrome sur mobile. Lorsque vous comparez des données CrUX, veillez à effectuer des comparaisons similaires en filtrant par type d'appareil et par navigateur Chrome.
Échantillonnage
Les solutions RUM permettent généralement d'ajuster le taux d'échantillonnage des visiteurs qui ont accepté de participer lorsque des données sont collectées. Cela permet de réduire le volume de données à analyser et les coûts des services RUM commerciaux. Si cet échantillon est trop petit et n'est pas représentatif d'une population plus large, les métriques qui en résultent seront également biaisées de la même manière. Discutez avec votre fournisseur de RUM de la taille d'échantillon appropriée pour votre site.
Agrégation des données
De par leur nature, les données de champ incluent un très grand nombre de points de données associés aux mêmes métriques que les données de test, qui ne donnent qu'une seule valeur. Si ces données sont agrégées différemment pour les rapports, cela peut entraîner une autre raison des différences entre CrUX et RUM.
Période
Les données CrUX sont basées sur une période de trafic glissante de 28 jours. Il n'est pas possible de modifier cette période. Toutefois, les données BigQuery sont stockées pour chaque mois, ce qui vous permet de voir les mois précédents.
Les données RUM offrent généralement des données beaucoup plus précises pour voir l'impact des changements beaucoup plus tôt. Toutefois, lorsque vous choisissez des périodes plus courtes, les données RUM peuvent être excessivement affectées par les fluctuations du trafic sur le site Web et du nombre de visiteurs. Lorsque vous comparez des données RUM à des données CrUX, assurez-vous toujours d'examiner les performances sur 28 jours. Une fois que vous êtes satisfait que les données sont similaires, vous pouvez examiner d'autres périodes pour explorer les données RUM.
Agrégation des statistiques
Les métriques CrUX sont mesurées au 75e centile, c'est-à-dire en examinant la valeur générée par 75% des pages vues. Les données réelles seront extrêmes et les 25% d'expérience les moins élevés seront supprimés. L'objectif est d'offrir une valeur que la majorité des visiteurs peut raisonnablement attendre d'atteindre.
Les produits RUM offrent souvent un plus grand nombre d'options d'agrégation des métriques, y compris le 75e centile, la médiane et d'autres centiles. Si vous comparez des valeurs RUM à des données CrUX, vous devez vous assurer que vous examinez les données du 75e centile pour les comparer.
Les données d'histogramme disponibles dans CrUX incluent toutes les données disponibles (pas seulement le 75e centile) et indiquent le nombre de pages vues pour chaque note. Le score global est basé sur le 75e centile. Ces données CrUX sont disponibles dans des outils tels que PageSpeed Insights:
Différences au niveau des métriques
De nombreuses métriques permettent de mesurer les performances Web. Par conséquent, lorsque vous comparez deux ensembles de données, il est important de comprendre quelles métriques sont mesurées et comment elles sont utilisées.
Métriques mesurées
Les données CrUX constituent l'ensemble de données officiel de l'initiative Core Web Vitals. Elles mesurent principalement ces trois métriques (LCP, FID et CLS), auxquelles s'ajoutent quelques métriques supplémentaires.
Les outils RUM incluent généralement ces Core Web Vitals, mais ils incluent aussi souvent de nombreuses autres métriques. Certains fournisseurs de RUM mesurent également l'expérience utilisateur en utilisant leur propre combinaison de toutes ces métriques, pour donner un indice de bonheur ou un autre type de valeur. Lorsque vous comparez des données RUM à CrUX, assurez-vous de comparer des données de manière similaire.
Les outils qui évaluent l'état de réussite ou d'échec des Core Web Vitals doivent tenir compte de la réussite d'une page si elle répond aux objectifs recommandés au 75e centile pour l'ensemble des Core Web Vitals. Si le FID n'est pas présent pour les pages sans interactions, seuls le LCP et le CLS doivent être transmis.
Différences de métriques entre les navigateurs
La fonctionnalité CrUX ne fonctionne que dans les navigateurs Chrome. Vous pouvez consulter le journal des modifications des métriques Web Vitals pour découvrir ce qui change pour chaque version de Chrome.
Les solutions RUM, en revanche, permettent d'effectuer des mesures à partir d'une plus grande variété de navigateurs. Les navigateurs basés sur Chromium (Edge, Opera, etc.) seront probablement semblables à Chrome, sauf si Chrome implémente de nouvelles modifications comme indiqué dans le journal des modifications.
Pour les navigateurs autres que Chromium, les différences peuvent être plus prononcées. La stratégie First Contentful Paint (FCP), par exemple, est disponible dans Safari et Firefox, mais elle est mesurée différemment. Cela peut entraîner des écarts importants dans les heures indiquées. Comme indiqué précédemment, si vous souhaitez comparer RUM et CrUX, il est préférable de filtrer uniquement les utilisateurs Chrome pour obtenir une comparaison similaire.
Planification des métriques
Les métriques Core Web Vitals sont fournies par les API des navigateurs Web, mais cela ne signifie pas qu'il n'y a pas de différences entre les valeurs signalées en les utilisant. Le moment exact de la mesure des métriques (au chargement de la page ou tout au long du cycle de vie de la page) peut entraîner des différences. Les outils RUM ne mesurent pas toujours les métriques de la même manière (même s'ils utilisent les mêmes noms) et avec les mêmes API de navigateur pour obtenir les données, ce qui peut être déroutant.
La métrique LCP (Largest Contentful Paint) est une métrique de chargement de page. Un certain nombre d'éléments LCP peuvent être signalés par l'API Web si des éléments plus volumineux sont chargés ultérieurement après le rendu initial. Le dernier élément LCP correspond à la fin du chargement de la page ou à l'interaction de l'utilisateur avec elle. Des différences peuvent donc apparaître si l'élément LCP est signalé avant ces deux événements.
De plus, dans les données de champ, l'élément LCP peut varier en fonction du chargement de la page. Pour un chargement de page par défaut affichant le haut du contenu de la page, l'élément LCP dépend principalement de la taille de l'écran. Toutefois, si la page est ouverte avec un lien d'ancrage plus bas dans le document ou via un lien profond vers une application monopage (nous y reviendrons plus en détail ultérieurement), l'élément LCP peut être différent.
Ne partez pas du principe que les durées LCP fournies dans CrUX ou RUM sont basées sur le même élément que les outils de l'atelier. Bien que CrUX vous indique la valeur LCP globale par page ou origine, le RUM peut la segmenter davantage afin d'identifier les sessions individuelles qui posent problème au LCP.
Le Cumulative Layout Shift (CLS) est mesuré tout au long de la vie de la page. Par conséquent, le CLS de chargement initial de la page peut ne pas être représentatif des pages qui entraînent des décalages plus importants plus tard après le chargement de la page et l'interaction de l'utilisateur avec celle-ci. Prendre la valeur CLS uniquement après le chargement de la page, comme le font de nombreux produits RUM, donnera donc un résultat différent de celui obtenu une fois que l'utilisateur a terminé de parcourir la page.
Le FID (First Input Delay) nécessite de mesurer une entrée. Il ne peut donc pas être mesuré au chargement de la page. Toutefois, comme son nom l'indique, FID ne mesure que la première entrée. La nouvelle métrique de réactivité Interaction to Next Paint (INP) mesure toutes les interactions au cours de la vie de la page, d'une manière semblable au CLS. Par conséquent, la valeur INP enregistrée peut être très différente si elle est mesurée après que l'utilisateur a effectué un certain nombre d'interactions sur la page.
CrUX suivra la documentation sur les métriques Core Web Vitals et mesurera ces métriques pendant toute la durée de vie de la page. De nombreux fournisseurs de rUM choisissent plutôt de mesurer ces métriques soit après le chargement de la page, soit à un autre moment (par exemple, lorsqu'un utilisateur clique sur une incitation à l'action clé) pour diverses raisons.
Lorsque vous constatez des écarts inexpliqués entre les deux sources de données, il est important que votre fournisseur de RUM comprenne quand les métriques Core Web Vitals sont mesurées.
Applications monopages
Les applications monopages (SPA) fonctionnent en mettant à jour le contenu de la page actuelle, au lieu d'effectuer une navigation classique sur les pages au niveau du navigateur. Cela signifie que le navigateur ne les voit pas comme des navigations sur les pages, bien que les utilisateurs les voient comme telles. Les API Core Web Vitals fournies par le navigateur ne tiendront pas compte de ces éléments. Par conséquent, CrUX n'est actuellement pas compatible avec ces navigations sur les pages. Nous travaillons actuellement à la résolution de ce problème. Pour en savoir plus, consultez le post Tester la mesure de la navigation douce.
Certains fournisseurs de RUM tentent de détecter les "navigations douces" dans les applications monopages, mais s'ils attribuent également les métriques Core Web Vitals à ces "navigations douces", cela entraînera des différences avec CrUX, car les API sous-jacentes ne sont pas compatibles.
Différences entre CrUX et API Web
Outre les différences concernant quelles pages vues sont mesurées et ce qui est mesuré, il existe d'autres scénarios plus complexes à prendre en compte qui peuvent entraîner des différences dans les données CrUX et RUM. Certains de ces problèmes sont dus aux limites des API Web utilisées pour mesurer les métriques. Dans d'autres cas, les résultats renvoyés par l'API doivent être traités différemment selon les scénarios. La documentation Core Web Vitals répertorie ces différences pour le LCP, le CLS et le FID, mais les principales différences sont indiquées ci-dessous.
Cache amélioré
CrUX considère les restaurations du cache amélioré (ou cache amélioré) comme des navigations sur les pages, même si elles n'entraînent pas un chargement de page classique. Comme les API Web ne traitent pas cela comme un chargement de page, les solutions RUM doivent prendre des étapes supplémentaires pour que ces pages soient comptabilisées si elles souhaitent établir une correspondance avec CrUX. Il s'agit d'un chargement de page beaucoup plus rapide, qui peut entraîner de meilleures performances globales pour un site. Par conséquent, si vous ne les incluez pas, vous risquez d'enregistrer de moins bonnes performances globales de la page. Reportez-vous à votre solution RUM pour savoir si elle gère les pages restaurées via le cache amélioré.
Cadres iFrame
Pour des raisons de sécurité et de confidentialité, les pages de premier niveau n'ont pas accès au contenu des iFrames (pas même des iFrames de même origine). Autrement dit, les métriques de performances du contenu de ces cadres ne peuvent être mesurées que par l'iFrame lui-même, et non via les API Web sur la page de cadres. Si le contenu de l'iFrame inclut l'élément LCP ou un contenu ayant un impact sur le CLS, le FID ou l'INP rencontré par l'utilisateur, les solutions RUM (y compris la bibliothèque JavaScript Google Web-Vitals) ne pourront pas y accéder.
En revanche, le CrUX ne présente pas ces limites, car il est mesuré par le navigateur Chrome lui-même plutôt que par la page. Il en va de même pour les métriques dans les cadres iFrame lors des rapports Core Web Vitals. Cette méthode permet de mieux refléter l'expérience des utilisateurs, mais peut aussi expliquer les différences entre les sites qui utilisent les cadres iFrame.
<video> est un exemple concret de la façon dont cela peut entraîner des différences entre les données LCP dans CrUX et RUM. La première image peinte d'un élément <video> en lecture automatique peut être considérée comme candidate LCP, mais les intégrations pour les services de streaming vidéo populaires peuvent placer ces éléments dans une <iframe>. Depuis août 2023, CrUX peut en tenir compte, car elle peut accéder au contenu <iframe>, mais pas les solutions RUM.
Ressources multi-origines
Les médias LCP diffusés depuis d'autres domaines n'accordent pas de délai d'affichage dans l'API PerformanceObserver, sauf si l'en-tête Timing-Allow-Origin (TAO) est fourni, en raison des restrictions de sécurité du navigateur visant à réduire les attaques de code temporel. Ce temps de chargement correspond au temps de chargement de la ressource, mais il peut être très différent du moment où le contenu a été réellement peint.
Cela peut entraîner une situation en apparence impossible, dans laquelle le LCP est signalé par les API Web comme étant antérieur au FCP. Ce n'est pas le cas, mais cela n'est le cas qu'en raison de cette restriction de sécurité.
Là encore, CrUX enregistre les données sur le délai d'affichage des Core Web Vitals. Il est recommandé aux sites de limiter le contenu multi-origine qui a une incidence sur les métriques Core Web Vitals et d'activer le TAO dans la mesure du possible s'ils souhaitent mesurer cela plus précisément. Les autres ressources multi-origines peuvent être soumises à des restrictions similaires.
Onglets en arrière-plan et prérendu
Lorsqu'une page n'est pas ouverte au premier plan, par exemple si elle utilise des options de prérendu (en cours de développement pour Chrome), elle continue à émettre des métriques via des API Web. Toutefois, elles ne sont pas signalées par CrUX, car elles offrent des délais incompatibles avec l'expérience utilisateur. Les solutions RUM doivent également envisager de les ignorer, ou du moins d'expliquer comment ces pages vues sont traitées.
Que pouvons-nous donc faire ?
Nous avons montré pourquoi il peut y avoir des différences entre les données CrUX et RUM, soit en raison de différences de méthodologie utilisées par chaque utilisation, soit en raison de l'inclusion ou de l'exclusion des utilisateurs et des pages vues. Dans l'idéal, ces deux ensembles de données seront tout de même représentatifs des performances de votre site, mais cet article devrait expliquer pourquoi il est très peu probable qu'ils obtiennent exactement les mêmes chiffres pour chacun d'eux.
Lorsque les différences sont légères (par exemple, un LCP de 2,0 secondes contre 2,2 secondes), les deux ensembles de données sont utiles et peuvent généralement être considérés comme étant à peu près synchronisés.
Lorsque des différences prononcées vous obligent à remettre en question l'exactitude des données, vous devez essayer de les comprendre. Est-il possible de filtrer les données RUM pour mieux correspondre à l'expérience utilisateur Chrome (en se basant uniquement sur les utilisateurs de Chrome, sur ordinateur ou sur mobile, avec des valeurs du 75e centile sur 28 jours) afin de réduire ces différences ?
Si c'est le cas, et que vous pouvez obtenir une correspondance plus étroite entre les données, vous devez toujours vous demander pourquoi vous constatez ces différences dans les données globales et ce que cela signifie. Les métriques sont-elles faussées de manière positive ou négative par les utilisateurs qui n'utilisent pas Chrome ? Cela vous donne-t-il plus d'informations sur les problèmes de performances que vous pouvez prioriser ?
Si vos utilisateurs qui n'utilisent pas Google Chrome obtiennent des résultats différents, vous pouvez utiliser ces informations précieuses fournies par RUM pour optimiser vos campagnes de façon différente. Par exemple, certaines API ne sont pas disponibles dans certains navigateurs, mais vous pouvez envisager des alternatives pour les navigateurs non compatibles afin d'améliorer leur expérience. Vous pouvez également offrir une expérience différente, mais plus performante aux utilisateurs d'appareils ou de réseaux limités. CrUX se limite aux données Chrome, mais vous devez prendre en compte l'expérience de tous les visiteurs de votre site pour prioriser les améliorations. Les données RUM peuvent combler cette lacune.
Une fois que vous avez compris les raisons de ces différences, les deux outils peuvent être incroyablement utiles pour comprendre l’expérience utilisateur de votre site Web et pour vous aider à l’améliorer même si les chiffres ne sont pas identiques. Utilisez vos données RUM pour compléter les données CrUX. De plus, vous pouvez analyser ce que vous dit l'expérience utilisateur de manière générale en segmentant votre trafic afin de déterminer si des sections spécifiques de votre site ou de votre base d'utilisateurs requièrent votre attention.
Il est souvent plus important d'examiner les tendances pour déterminer si vos améliorations ont l'impact positif attendu que de faire correspondre exactement chaque chiffre entre les deux sources de données. Comme mentionné ci-dessus, le RUM vous permet d'examiner différentes périodes afin d'avoir une idée de vos scores CrUX sur 28 jours. Toutefois, regarder des périodes trop courtes peut entraîner du bruit dans les données, d'où la raison pour laquelle CrUX utilise 28 jours.
Souvent, il n'y a pas de « bonne » ou de « mauvaise » réponse dans ces différentes métriques. Ils ont simplement une vision différente de vos utilisateurs et de la façon dont ils utilisent votre site. Tant que vous comprenez pourquoi ces différences se produisent et ce que cela peut faire pour orienter votre prise de décision, c'est le plus important pour mieux répondre aux besoins des visiteurs de votre site.
Remerciements
Image principale de Steven Lelham sur Unsplash