Découvrez pourquoi les données RUM peuvent afficher des valeurs Core Web Vitals différentes de celles de CrUX.
Le rapport d'expérience utilisateur Chrome (CrUX) fournit des métriques sur l'expérience utilisateur Chrome réelle des destinations populaires sur le Web. Ces données sont automatiquement collectées par Chrome auprès des utilisateurs qui ont activé cette fonctionnalité et sont mises à disposition en fonction des critères d'éligibilité du rapport CrUX.
Les données CrUX sont donc disponibles pour des millions de sites Web. De nombreux propriétaires de sites n'avaient jamais eu accès aux données sur le terrain auparavant. CrUX leur a permis de découvrir leur utilité pour la première fois. En tant qu'ensemble de données public, le rapport d'expérience utilisateur Chrome peut également être utilisé pour effectuer une analyse concurrentielle et une analyse comparative des métriques d'expérience utilisateur.
La surveillance de l'expérience utilisateur réelle (RUM) est semblable à CrUX. Cependant, au lieu que Chrome collecte automatiquement les métriques sur l'expérience utilisateur, du code est inclus sur les sites Web pour effectuer cette collecte et la transmettre à un fournisseur de RUM ou à une solution d'analyse pour une analyse plus approfondie.
Étant donné que les deux solutions mesurent des métriques d'expérience utilisateur, il est naturel de supposer qu'elles devraient être équivalentes. Il peut être déroutant de constater des différences. Ce guide vous explique pourquoi cela peut se produire et vous propose des suggestions pour savoir quoi faire lorsque les chiffres ne correspondent pas.
Avantages de compléter CrUX avec une solution RUM
Le rapport CrUX est un excellent outil pour obtenir une vue cohérente sur les différents sites. En tant qu'ensemble de données officiel du programme Core Web Vitals, les sites voudront probablement garder un œil sur ce qu'il indique. L'objectif de CrUX est de fournir une vue d'ensemble statistiquement pertinente de millions de sites Web à des fins de comparaison.
Toutefois, pour comprendre plus en détail pourquoi les données affichent les chiffres qu'elles affichent, investir dans une solution RUM complète en complément de CrUX peut vous donner accès à des informations plus détaillées que celles disponibles dans un ensemble de données publics. Cela peut vous aider à expliquer et à améliorer vos métriques de plusieurs façons.
Analyse plus approfondie pour examiner les problèmes
Le CrUX peut souvent vous indiquer si vous rencontrez un problème sur votre site, mais pas nécessairement exactement où se trouve le problème ni pourquoi. Les solutions RUM, qu'elles soient développées en interne à l'aide de outils comme la bibliothèque Web Vitals ou de l'un 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 précises pour toutes vos pages et sur tous les navigateurs. Il vous permet également de segmenter et d'analyser ces données d'une manière différente de CrUX, ce qui vous permet d'examiner en détail les problèmes du site. Sont-ils affectés par un segment d'utilisateurs particulier ? ou les utilisateurs qui effectuent certaines actions ? À quel moment précis le problème a-t-il commencé ? Ces questions sont beaucoup plus faciles à répondre avec les données supplémentaires qu'un outil de RUM peut fournir.
Corréler les données avec d'autres métriques commerciales
La RUM vous permet également de comparer directement vos métriques de performances Web à n'importe quelle métrique commerciale, ce qui vous montre l'intérêt d'investir dans les performances et les autres tâches de performances à prioriser. Nous avons de nombreuses études de cas d'entreprises qui effectuent cette corrélation, comme Farfetch ou The Economic Times.
Collecter d'autres données sur les performances
Une solution RUM permet de collecter d'autres métriques personnalisées, directement liées à votre activité spécifique. L'un des exemples les plus connus est la métrique Temps avant le premier tweet de Twitter. Ces mesures spécifiques au site peuvent ensuite être mises en corrélation avec les améliorations des Core Web Vitals et les métriques métier.
Différences entre deux ensembles de données sur le terrain
Un homme avec une montre sait quelle heure il est. Un homme avec deux montres n'est jamais sûr.
Loi de Segal
Lorsque vous disposez de deux sources de données, il peut être difficile de comprendre pourquoi elles diffèrent. Tout comme il est important de comprendre la différence entre les métriques de laboratoire et de terrain, il peut également y avoir des différences entre deux sources de données sur le terrain. Dans un monde idéal, les données seraient les mêmes, mais il existe de nombreuses raisons pour lesquelles elles peuvent différer.
Données de laboratoire par rapport aux données sur le terrain
La première chose à vérifier est si vous examinez des métriques en laboratoire (synthétiques) ou sur le terrain (RUM). Bien qu'il soit naturel de penser que les produits RUM ne s'intéressent qu'aux données sur le terrain, beaucoup d'entre eux proposent également un composant de laboratoire.
Les données de laboratoire sont extrêmement utiles précisément en raison des conditions fixes dans lesquelles elles sont mesurées. Il peut être utilisé pour surveiller les changements ou les régressions inattendus dans un environnement de production, sans le bruit généré par la modification de la population des champs. Toutefois, les données de laboratoire ne sont pas nécessairement représentatives de l'expérience utilisateur réelle. Par conséquent, les métriques sur le terrain peuvent 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 en raison des visites de pages mesurées en fonction des navigateurs, des utilisateurs, des sites et des appareils comparés.
Navigateurs inclus
Comme son nom l'indique, le rapport d'expérience utilisateur Chrome est réservé à Chrome. De nombreux navigateurs basés sur Chromium (Edge, Opera et Brave, pour n'en citer que quelques-uns) sont compatibles avec les mêmes métriques que Chrome en raison du code de base principal partagé. Toutefois, seuls les utilisateurs de Chrome envoient des données à CrUX. Cette restriction signifie également que les utilisateurs de Chrome sur iOS ne sont pas inclus, car ils utilisent le moteur de navigateur Webkit sous-jacent. Les WebViews Android ne sont pas non plus considérées comme "Chrome". Par conséquent, les données de ces utilisateurs ne sont pas incluses, mais les onglets personnalisés Chrome le sont.
Bien que Chrome soit l'un des navigateurs les plus populaires au monde et qu'il offre donc une représentation globale des performances de votre site dans la plupart des cas, mesurer uniquement ce navigateur ne vous permet pas de mesurer l'ensemble de vos utilisateurs. Cela peut expliquer une différence principale entre le RUM et CrUX. C'est particulièrement vrai pour les techniques de performances qui reposent sur des API ou des formats d'image disponibles uniquement dans Chrome, par exemple.
Le manque de données iOS peut également entraîner des biais. Par exemple, les utilisateurs iOS utilisent généralement des appareils plus performants ou se trouvent dans des pays disposant d'une meilleure infrastructure réseau. Leur inclusion peut donc entraîner des métriques de performances globales élevées. En revanche, les exclure (comme le fait CrUX) peut entraîner des données biaisées vers les visiteurs les moins fréquents du site (exemple d'étude de cas). Les utilisateurs Android couvrent généralement un plus grand nombre d'appareils, de fonctionnalités et de marchés.
Les solutions RUM peuvent obtenir des données pour les navigateurs autres que Chrome, en particulier les navigateurs Chromium qui intègrent souvent les mêmes métriques (telles que les Core Web Vitals). Les navigateurs autres que Chromium sont également mesurés par des solutions RUM, mais leur ensemble de métriques peut être plus limité. Par exemple, le Cumulative Layout Shift (CLS) (Déplacement cumulé de la mise en page) et l'Interaction to Next Paint (INP) (Interaction avant la prochaine peinture) ne sont disponibles que dans les navigateurs basés sur Chromium. D'autres métriques, comme le First Contentful Paint (FCP), peuvent être mesurées de manière très différente (voir plus loin).
Utilisateurs activés
En plus d'être limité aux utilisateurs de Chrome, CrUX ne mesure qu'un sous-ensemble d'utilisateurs de Chrome qui ont activé le partage des données CrUX lors de l'installation du navigateur.
Les fournisseurs de RUM ne regardent également qu'un sous-ensemble d'utilisateurs, généralement en raison des invites de bannière de cookie (qui demandent aux utilisateurs d'activer la collecte des données RUM) ou des bloqueurs de suivi. Cela peut avoir un impact négatif sur certains chargements de pages initiaux si la confirmation n'est pas donnée avant la deuxième page ou les pages suivantes, alors que 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 RUM qu'elles ne le sont en réalité si les chargements de pages initiaux plus lents sont exclus dans un nombre suffisant de cas.
Sites inclus
Le rapport CrUX n'est destiné qu'à générer des rapports sur les sites Web publics. Il existe donc d'autres critères d'éligibilité qui peuvent entraîner l'absence de données dans le rapport CrUX. Le plus important de ces critères est que le site Web doit être accessible au public et suffisamment populaire pour garantir une taille d'échantillon minimale à partir de laquelle des conclusions pertinentes peuvent être tirées. Dans la plupart des cas, aucune donnée n'est disponible dans CrUX. Cette différence est moins déroutante que les données disponibles, mais différentes, 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 est possible que vous ne voyiez qu'un sous-ensemble d'URL dans CrUX. Si l'origine est publiquement accessible, toutes les vues de page de cette origine seront incluses dans les données au niveau de l'origine, mais les données au niveau de l'URL peuvent ne pas être disponibles.
Appareils
CrUX segmente les données par appareil mobile, ordinateur et tablette, bien que de nombreux outils se concentrent sur les deux premiers et ne présentent pas les données sur les tablettes, ou les incluent dans les données sur les appareils mobiles ou les ordinateurs. Les caractéristiques de performances sur mobile et sur ordinateur peuvent être très différentes, à la fois en termes de contenu diffusé et de fonctionnalités des appareils qui le lisent.
Les données RUM permettent de segmenter le trafic de la même manière, mais elles affichent souvent des données consolidées par défaut. La RUM ne permet peut-être de segmenter que par type d'appareil (par exemple, mobile) ou par navigateur (par exemple, Chrome), mais pas les deux pour afficher uniquement le trafic Chrome sur mobile. Lorsque vous comparez les données CrUX, assurez-vous de comparer des données comparables 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 ayant activé la collecte de données. Cela permet de réduire le volume de données à analyser et de réduire les coûts des services commerciaux de RUM. Si cette taille d'échantillon est trop faible et qu'elle n'est pas représentative de la population plus large, les métriques qui en résultent seront également faussées. Discutez avec votre fournisseur de RUM de la taille d'échantillonnage appropriée pour votre site.
Agrégation des données
Par nature, les données sur le terrain incluront de très nombreux points de données pour les mêmes métriques, contrairement aux données de laboratoire, qui ne donnent qu'une seule valeur. Si ces données sont agrégées différemment pour les rapports, cela peut entraîner d'autres différences entre CrUX et RUM.
Période
Les données CrUX sont basées sur une période glissante de 28 jours pour le trafic. Il n'est pas possible de modifier cette période. Toutefois, les données BigQuery CrUX sont stockées pour chaque mois, ce qui vous permet de consulter les mois précédents. L'API CrUX History fournit également des données historiques sur une période hebdomadaire. Les deux fournissent toujours des données basées sur la période glissante de 28 jours.
Les données RUM permettent généralement d'obtenir une granularité beaucoup plus élevée, ce qui permet de voir plus rapidement l'impact des modifications. Toutefois, lorsque vous choisissez des périodes plus courtes, les données RUM peuvent être trop affectées par les fluctuations du trafic et des visiteurs sur le site Web. Lorsque vous comparez les données RUM aux données CrUX, veillez toujours à examiner les performances sur une période de 28 jours. Une fois que vous êtes convaincu que les données sont similaires, vous pouvez examiner d'autres périodes pour examiner les données RUM.
Agrégation des statistiques
Les métriques CrUX sont mesurées au 75e centile, c'est-à-dire en tenant compte de la valeur atteinte par 75% des pages vues. Les données sur le terrain présentent des extrêmes. En supprimant les 25% d'expériences les plus mauvaises, vous obtiendrez une valeur que la majorité des visiteurs peut raisonnablement atteindre.
Les produits RUM offrent souvent un plus grand nombre d'options pour agréger les métriques, y compris le 75e centile, la médiane et d'autres centiles. Si vous comparez les valeurs RUM aux données CrUX, vous devez vous assurer que vous examinez les données du 75e percentile pour effectuer une comparaison juste.
Les données de l'histogramme dans CrUX incluent toutes les données disponibles (et pas seulement le 75e centile) et affichent le nombre de pages vues pour chaque note, mais le score agrégé est basé sur le 75e centile. Ces données CrUX sont présentées dans des outils tels que PageSpeed Insights:
Différences entre les métriques
De nombreuses métriques sont utilisées pour mesurer les performances Web. Par conséquent, lorsque vous comparez deux ensembles de données différents, 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 métriques (LCP, CLS et INP), avec quelques métriques supplémentaires pour les compléter.
Les outils RUM incluent généralement ces métriques Web Vitales de base, mais aussi de nombreuses autres métriques. Certains fournisseurs de RUM mesurent également l'expérience utilisateur à l'aide de leur propre combinaison de toutes ces métriques, par exemple pour fournir un "indice de satisfaction". Lorsque vous comparez les données RUM à CrUX, assurez-vous de comparer des données comparables.
Les outils qui évaluent l'état des Core Web Vitals (réussite ou échec) doivent considérer qu'une page a réussi si elle atteint les cibles recommandées au 75e percentile pour toutes les métriques. Si l'INP n'est pas présent pour les pages sans interactions, seuls le LCP et le CLS doivent être acceptés.
Différences entre les métriques des navigateurs
CrUX ne mesure que dans les navigateurs Chrome. Vous pouvez consulter les journaux des modifications de Web Vitals pour voir comment ces mesures évoluent avec chaque version de Chrome.
En revanche, les solutions RUM mesurent les données à partir d'un plus grand nombre de navigateurs. Les navigateurs basés sur Chromium (Edge, Opera, etc.) seront probablement similaires à 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. Par exemple, First Contentful Paint (FCP) est disponible dans Safari et Firefox, mais il est mesuré différemment. Cela peut entraîner des écarts importants entre les heures indiquées. Comme indiqué précédemment, si vous souhaitez comparer le RUM à CrUX, il est préférable de filtrer uniquement les utilisateurs Chrome pour permettre une comparaison en toute équité.
Calendrier 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 possibles entre les valeurs enregistrées à l'aide de ces API. Le moment exact où la mesure de la métrique est effectuée (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 n'utilisent pas toujours les mêmes API de navigateur pour obtenir les données, ce qui peut prêter à confusion.
Le LCP (Largest Contentful Paint) est une métrique de chargement de page. La Web API peut signaler un certain nombre d'éléments LCP si des éléments plus volumineux sont chargés plus tard après le rendu initial. L'élément LCP final correspond au moment où la page a fini de se charger ou où l'utilisateur interagit avec elle. Par conséquent, des différences peuvent 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 être différent selon la façon dont la page est chargée. 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 à l'aide d'un lien d'ancrage plus loin dans le document, ou de manière similaire à l'aide d'un lien profond dans une application monopage (SPA), l'élément LCP peut être différent.
Ne partez pas du principe que les temps de LCP fournis dans CrUX ou RUM sont basés sur le même élément que les outils de laboratoire. CrUX vous indique la valeur LCP globale par page ou origine, mais RUM peut la segmenter davantage pour identifier les sessions présentant des problèmes LCP individuels.
Le CLS (Cumulative Layout Shift) est mesuré tout au long de la durée de vie de la page. Par conséquent, le CLS initial du chargement de la page peut ne pas être représentatif des pages qui provoquent des décalages plus importants plus tard, une fois la page chargée et que l'utilisateur a interagi avec elle. Si vous ne prenez en compte la valeur CLS qu'après le chargement de la page (comme le font de nombreux produits RUM), vous obtiendrez un résultat différent de celui obtenu si vous prenez en compte la valeur CLS après que l'utilisateur a terminé d'utiliser la page.
La métrique de réactivité Interaction to Next Paint (INP) nécessite une entrée pour être mesurée et observe toutes les interactions (clic, appui et commandes au clavier) au cours de la durée de vie de la page, comme le CLS. Par conséquent, la valeur indiquée pour l'INP 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 Core Web Vitals et les mesurera tout au long de la durée de vie de la page. Pour diverses raisons, de nombreux fournisseurs de RUM choisissent de mesurer ces métriques après le chargement de la page ou à un autre moment (par exemple, lorsqu'un utilisateur clique sur un incitant à l'action clé).
Il est important de demander à votre fournisseur de RUM quand les Core Web Vitals sont mesurés lorsque vous constatez des écarts inexpliqués entre les deux sources de données.
Applications monopages
Les applications monopages (SPA, Single Page Application) fonctionnent en mettant à jour le contenu de la page actuelle, plutôt qu'en effectuant des navigations de page réelles au niveau du navigateur. Cela signifie que le navigateur ne les considère pas comme des navigations de page, même si les utilisateurs les perçoivent comme telles. Les API Core Web Vitals fournies par le navigateur ne les prennent pas en compte. Par conséquent, CrUX n'est pas compatible avec ces navigations de pages. Nous travaillons actuellement à la résolution de ce problème. Pour en savoir plus, consultez l'article Tester la mesure des navigations douces.
Certains fournisseurs de RUM tentent de détecter les "navigations douces" dans les SPA, mais s'ils attribuent également des métriques Core Web Vitals à ces "navigations douces", des différences apparaîtront avec CrUX, car les API sous-jacentes ne sont pas compatibles avec de nombreuses métriques.
Différences entre CrUX et l'API Web
En plus des différences entre les vues de pages mesurées et les éléments mesurés, il existe d'autres scénarios plus complexes à prendre en compte qui peuvent entraîner des différences entre les données CrUX et RUM. Certaines de ces différences sont dues aux limites des API Web utilisées pour mesurer les métriques, et d'autres sont liées au fait que les résultats renvoyés par l'API doivent être traités différemment dans certains scénarios. La documentation sur les Core Web Vitals liste ces différences pour le LCP et le CLS, mais les principales différences sont également indiquées dans les sections suivantes.
Cache amélioré
CrUX considère les restaurations du cache amélioré (ou bfcache) comme des navigations de page, même si elles ne génèrent pas de chargement de page classique. Comme les API Web ne les traitent pas comme une page chargée, les solutions RUM doivent prendre des mesures supplémentaires pour que ces pages soient comptabilisées si elles souhaitent correspondre à CrUX. Ces chargements de pages sont beaucoup plus rapides et peuvent entraîner de meilleures performances globales pour un site. Si vous ne les incluez pas, les métriques de performances globales des pages peuvent être moins bonnes. Reportez-vous à votre solution RUM pour savoir si elle gère les pages restaurées à partir de bfcache.
iFrames
Pour des raisons de sécurité et de confidentialité, les pages de premier niveau n'ont pas accès au contenu des iFrames (même les iFrames de même origine). Cela signifie que les métriques de performances des contenus de ces pages ne peuvent être mesurées que par l'iFrame elle-même, et non via les API Web de la page de cadrage. Si le contenu de l'iFrame inclut l'élément LCP ou un contenu qui a un impact sur le CLS ou l'INP de l'utilisateur, il ne sera pas disponible pour les solutions RUM (y compris la bibliothèque JavaScript Google Web Vitals).
Cependant, le rapport CrUX, qui est mesuré par le navigateur Chrome lui-même plutôt que par JavaScript sur la page, ne présente pas ces limites et mesure donc les métriques dans les iFrame lors de la création de rapports sur les Core Web Vitals. Cela reflète plus précisément l'expérience utilisateur, mais peut être une autre raison de différences pour les sites qui utilisent des iFrames.
Un exemple concret de la façon dont cela peut entraîner des différences entre les données LCP dans CrUX et RUM est l'<video>
intégrée. Le premier frame peint d'un élément <video>
autojouant avec "playsinline" peut être considéré comme un candidat au LCP, mais les éléments intégrés pour les services de streaming vidéo populaires peuvent placer ces éléments dans un <iframe>
. CrUX peut en tenir compte, car il peut accéder au contenu <iframe>
, mais les solutions RUM ne le peuvent pas.
Ressources multi-domaines
Les contenus multimédias LCP diffusés à partir d'autres domaines peuvent ne pas indiquer le temps de rendu dans l'API PerformanceObserver, sauf si l'en-tête Timing-Allow-Origin (TAO) est fourni. En effet, les navigateurs imposent des restrictions de sécurité pour réduire les attaques par cassage de chiffrement. Cette valeur revient au temps de chargement de la ressource, mais il peut être très différent de celui auquel le contenu a été réellement peint.
Cela peut entraîner une situation apparemment impossible où le LCP est signalé par les API Web comme étant antérieur au FCP. Ce n'est pas le cas, mais cela apparaît uniquement en raison de cette restriction de sécurité.
Ce problème a été résolu fin 2024. Un temps de rendu légèrement ajusté est disponible à partir de Chrome 133, même si Timing-Allow-Origin
n'est pas fourni.
Encore une fois, CrUX indique les données de temps de rendu pour les Core Web Vitals. Nous recommandons aux sites de limiter les contenus inter-origines qui ont un impact 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. D'autres ressources multi-origines peuvent être soumises à des restrictions similaires.
Onglets en arrière-plan
Lorsqu'une page n'est pas ouverte dans un onglet en arrière-plan, elle émet toujours des métriques à l'aide d'API Web. Toutefois, elles ne sont pas enregistrées par CrUX, car elles fournissent des délais incohérents avec l'expérience utilisateur. Les solutions RUM doivent également envisager de les ignorer ou, au moins, d'expliquer comment ces pages vues sont traitées.
Que pouvons-nous faire ?
Nous avons expliqué pourquoi il peut y avoir des différences entre les données CrUX et RUM, soit en raison des différences de méthodologie entre les deux, soit en raison des utilisateurs et des pages vues inclus ou exclus. Dans l'idéal, les deux ensembles de données doivent toujours être représentatifs des performances de votre site pour être utiles. Toutefois, les raisons données doivent expliquer pourquoi il est très peu probable d'obtenir les mêmes chiffres exacts dans 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 à peu près synchronisés.
Lorsque des différences prononcées vous font douter de l'exactitude des données, vous devez essayer de comprendre ces différences. Les données RUM peuvent-elles être filtrées pour mieux correspondre à CrUX (en ne tenant compte que des utilisateurs Chrome, sur ordinateur ou mobile, avec des valeurs du 75e percentile sur 28 jours) afin de réduire ces différences ?
Si c'est le cas et que vous pouvez obtenir une correspondance plus étroite des données, vous devez tout de même vous demander pourquoi vous constatez ces différences dans les données globales et ce qu'elles signifient. Les utilisateurs qui ne sont pas Chrome faussent-ils vos métriques de manière positive ou négative ? Cela vous donne-t-il plus d'informations sur les problèmes de performances que vous pouvez hiérarchiser ?
Si vos utilisateurs non Chrome obtiennent des résultats différents, vous pouvez utiliser ces informations précieuses fournies par RUM pour optimiser votre site différemment. Par exemple, certaines API ne sont pas disponibles sur certains navigateurs, mais vous pouvez envisager d'autres solutions pour les navigateurs non compatibles afin d'améliorer leur expérience. Vous pouvez également proposer une expérience différente, mais plus performante aux utilisateurs sur des appareils ou des réseaux limités. Le rapport CrUX est limité aux données Chrome, mais vous devez tenir compte de l'expérience de tous les visiteurs de votre site pour déterminer les améliorations à prioriser. Les données RUM peuvent combler cette lacune.
Une fois que vous avez compris les raisons des différences, les deux outils peuvent être extrêmement utiles pour comprendre l'expérience utilisateur sur votre site Web et l'améliorer, même si les chiffres ne sont pas identiques. Utilisez vos données RUM pour compléter les données CrUX et vous permettre d'examiner ce que CrUX vous indique de manière globale en segmentant votre trafic. Vous pourrez ainsi identifier les zones spécifiques de votre site ou de votre base d'utilisateurs qui nécessitent votre attention.
Il est souvent plus important d'examiner les tendances pour vérifier que vos améliorations ont l'impact positif attendu que de s'assurer que chaque chiffre correspond exactement entre les deux sources de données. Comme indiqué précédemment, RUM vous permet d'examiner différentes périodes pour obtenir un aperçu de vos scores CrUX sur 28 jours. Toutefois, examiner des périodes trop courtes peut entraîner des données trop bruyantes. C'est pourquoi CrUX utilise une période de 28 jours.
Il n'y a souvent pas de réponse "correcte" ou "incorrecte" pour ces différentes métriques. Elles ne sont qu'un autre angle d'analyse de vos utilisateurs et de leur expérience sur votre site. Tant que vous comprenez pourquoi ces différences se produisent et comment elles peuvent vous aider à prendre des décisions, c'est l'essentiel pour mieux servir les visiteurs de votre site.
Remerciements
Image miniature par Steven Lelham sur Unsplash