Découvrez pourquoi les données RUM peuvent afficher des chiffres Core Web Vitals différents de ceux de CrUX.
Publié le 15 août 2022, dernière mise à jour le 17 décembre 2025
Le rapport sur l'expérience utilisateur de Chrome 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 accepté de les partager, et sont disponibles en fonction des critères d'éligibilité 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 de terrain auparavant, et CrUX a permis à de nombreux sites d'en voir la valeur 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.
Le Real User Monitoring (RUM) est semblable au CrUX, mais au lieu que Chrome collecte automatiquement les métriques d'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.
Comme 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 solutions lorsque les chiffres ne correspondent pas.
Avantages de compléter CrUX avec une solution RUM
CrUX est un excellent outil pour obtenir une vue cohérente sur l'ensemble des sites. En tant qu'ensemble de données Google pour le programme Core Web Vitals, les sites voudront probablement garder un œil sur ce qu'il affiche. L'objectif du rapport CrUX est de fournir un aperçu statistiquement pertinent de millions de sites Web à des fins de comparaison.
Toutefois, pour approfondir l'analyse des raisons pour lesquelles les données affichent les chiffres qu'elles affichent, investir dans une solution RUM complète pour compléter CrUX peut vous donner accès à des informations plus détaillées que celles qui peuvent être mises à disposition dans un ensemble de données interrogeable publiquement. Cela peut vous aider à expliquer et à améliorer vos métriques de plusieurs façons.
Analyse plus approfondie pour examiner les problèmes
CrUX peut souvent être utilisé pour signaler un problème sur votre site, mais pas nécessairement pour indiquer exactement où se trouve le problème ni pourquoi. Les solutions RUM, qu'elles soient développées en interne (comme la bibliothèque web-vitals) ou qu'il s'agisse de produits commerciaux, peuvent vous aider à combler cette lacune.
L'utilisation d'une solution RUM vous donne accès à 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 que CrUX ne permet pas, ce qui vous permet d'explorer et d'examiner les zones problématiques 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é ? Il est beaucoup plus facile de répondre à ces questions grâce aux données supplémentaires qu'un outil de RUM peut fournir.
Corréler avec d'autres métriques d'entreprise
Le RUM vous permet également de comparer directement vos métriques de performances Web avec n'importe quelle métrique d'entreprise, ce qui vous permet de voir l'intérêt d'investir dans les performances et de déterminer les autres tâches de performances à prioriser. Nous disposons de nombreuses études de cas d'entreprises qui ont établi 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 "Time to first Tweet" de Twitter. Ces mesures spécifiques au site peuvent ensuite être corrélées avec les améliorations des Core Web Vitals et les métriques d'activité.
Différences entre deux ensembles de données de terrain
Un homme avec une montre sait l'heure qu'il est. Un homme avec deux montres n'en est jamais sûr.
Loi de Segal
Lorsque vous disposez de deux sources de données, il peut être difficile et frustrant de comprendre pourquoi elles diffèrent. De la même manière qu'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 de terrain. Dans un monde idéal, les données seraient identiques, mais de nombreux facteurs peuvent expliquer les différences.
Données de laboratoire et données réelles
La première chose à vérifier est de savoir si vous examinez des métriques de laboratoire (synthétiques) ou de terrain (RUM). Bien qu'il soit naturel de supposer que les produits RUM ne s'intéressent qu'aux données de terrain, beaucoup 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 modifications ou régressions inattendues dans un environnement de production sans le bruit d'une population de champ changeante. Toutefois, les données de laboratoire ne sont pas forcément représentatives de l'expérience utilisateur réelle. Les métriques de terrain peuvent donc afficher des résultats assez différents.
Populations
Les ensembles de données utilisés par les solutions CrUX et RUM peuvent être différents en raison de différences dans la mesure des visites de pages, selon les navigateurs, les utilisateurs, les sites et les appareils comparés.
Navigateurs inclus
Comme son nom l'indique, le rapport sur l'expérience utilisateur de Chrome ne concerne que Chrome. Bien qu'il existe de nombreux navigateurs basés sur Chromium (Edge, Opera et Brave, pour n'en citer que quelques-uns) qui partagent une grande partie du codebase de Chrome, seuls les utilisateurs de Chrome transmettent des données à CrUX. Cette restriction signifie également que les utilisateurs de Chrome sur iOS ne sont pas inclus, car il utilise le moteur de navigateur Webkit sous-jacent. Les WebViews Android ne sont pas non plus comptabilisées comme "Chrome". Les données de ces utilisateurs ne sont donc pas incluses, bien que les onglets personnalisés Chrome le soient.
Chrome est l'un des navigateurs les plus populaires au monde et, par conséquent, il donne probablement une représentation générale des performances de votre site dans la plupart des cas. Toutefois, mesurer uniquement ce navigateur ne permet en aucun cas de mesurer l'ensemble de vos utilisateurs. Cela peut expliquer l'une des principales différences entre le RUM et le 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, comme les utilisateurs d'iOS utilisent généralement des appareils plus performants ou se connectent depuis des pays disposant d'une meilleure infrastructure réseau, les inclure peut 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 le bas de l'échelle des visiteurs du site (exemple d'étude de cas). Les utilisateurs d'Android couvrent généralement un plus grand nombre d'appareils, de fonctionnalités d'appareils et de marchés.
Les solutions RUM peuvent obtenir des données pour les navigateurs autres que Chrome, et en particulier pour les navigateurs basés sur Chromium qui intègrent souvent les mêmes métriques (comme les Core Web Vitals). Les navigateurs non basés sur Chromium sont également mesurés par les solutions RUM, mais peuvent disposer d'un ensemble de métriques plus limité. Par exemple, la métrique Cumulative Layout Shift (CLS) n'est disponible que dans les navigateurs basés sur Chromium. D'autres métriques basées sur l'affichage, comme le LCP, l'INP et même le First Contentful Paint (FCP), peuvent être mesurées de manière très différente (voir plus loin).
Utilisateurs ayant activé la fonctionnalité
En plus d'être limité aux utilisateurs de Chrome, le rapport CrUX est également limité, car il ne mesure qu'un sous-ensemble d'utilisateurs de Chrome qui ont accepté de partager les 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 des bannières de cookies (qui demandent aux utilisateurs d'accepter la collecte de données RUM) ou des bloqueurs de suivi. Cela peut avoir un impact négatif sur certains chargements de page initiaux si la confirmation n'est pas donnée avant la deuxième page ou les pages suivantes, 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 la surveillance des utilisateurs réels qu'elles ne le sont en réalité si les chargements de page initiaux plus lents sont exclus dans un nombre suffisant de cas.
Sites inclus
Le rapport CrUX n'est destiné qu'à rendre compte des sites Web publics. D'autres critères d'éligibilité peuvent donc empêcher l'enregistrement des données dans le rapport CrUX. Le critère le plus important est que le site Web doit être accessible au public 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 disponible dans CrUX. Cette différence est moins déroutante que lorsque les données sont disponibles, mais différentes. Elle explique pourquoi cela se produit.
Toutefois, si certaines pages d'un site sont marquées comme indexables, mais pas d'autres, il est possible que vous ne voyiez qu'un sous-ensemble d'URL dans CrUX. Si l'origine est détectable publiquement, toutes les pages vues de cette origine seront incluses dans les données au niveau de l'origine, mais les données au niveau de l'URL ne seront peut-être pas disponibles.
Appareils
CrUX segmente les données par mobile, ordinateur et tablette, bien que de nombreux outils se concentrent sur les deux premiers et n'exposent pas les données des tablettes, ou les incluent dans les données mobiles ou pour ordinateur. Les caractéristiques de performances sur mobile et sur ordinateur peuvent être très différentes, tant en termes de diffusion de contenu que de capacités des appareils qui l'affichent.
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. Le RUM ne permet de segmenter que par type d'appareil (par exemple, mobile) ou par navigateur (par exemple, Chrome), mais pas les deux pour ne voir que le trafic mobile Chrome. Lorsque vous comparez des données à celles de CrUX, assurez-vous de comparer des éléments 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 ayant accepté la collecte de données. Cela peut être utilisé pour réduire le volume de données à analyser et pour réduire les coûts des services RUM commerciaux. Si la taille de cet échantillon est trop petite et n'est pas représentative de la population globale, les métriques obtenues seront également biaisé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 de terrain incluent de très nombreux points de données pour les mêmes métriques, contrairement aux données de laboratoire, qui ne fournissent qu'une seule valeur. Si ces données sont agrégées différemment pour les rapports, cela peut expliquer 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 de trafic, et il n'est pas possible de modifier cette période. Toutefois, les données CrUX BigQuery sont stockées pour chaque mois, ce qui vous permet de voir les mois précédents, et 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 une précision beaucoup plus élevée, ce qui permet de voir l'impact des modifications beaucoup plus tôt. Toutefois, si vous choisissez des périodes plus courtes, les données RUM peuvent être indûment affectées par les fluctuations du trafic et des visiteurs du site Web. Lorsque vous comparez les données RUM aux données CrUX, assurez-vous toujours d'examiner les performances sur 28 jours. Une fois que vous êtes satisfait de la similarité des données, vous pouvez examiner d'autres périodes pour analyser les données RUM.
Agrégation de statistiques
Les métriques CrUX sont mesurées au 75e centile, c'est-à-dire en examinant la valeur atteinte par 75 % des pages vues. Les données de terrain peuvent présenter des valeurs extrêmes. En supprimant les 25 % d'expériences les moins bonnes, l'objectif est de fournir une valeur que la majorité des visiteurs peuvent raisonnablement s'attendre à 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 centile pour comparer des éléments comparables.
Les données de l'histogramme dans CrUX incluent toutes les données disponibles (pas seulement le 75e centile) et indiquent le nombre de pages vues pour chaque note, mais le score global sera basé sur le 75e centile. Ces données CrUX sont affiché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 Google de l'initiative Core Web Vitals et mesurent principalement ces métriques (LCP, CLS et INP), ainsi que quelques métriques supplémentaires pour les compléter.
Les outils RUM incluent généralement ces Core Web Vitals, mais aussi de nombreuses autres métriques. Certains fournisseurs de RUM mesurent également l'expérience utilisateur en combinant toutes ces métriques, par exemple pour fournir un "indice de satisfaction" ou autre. Lorsque vous comparez les données RUM à celles de CrUX, assurez-vous de comparer des éléments comparables.
Les outils qui évaluent l'état de réussite ou d'échec des Core Web Vitals doivent considérer qu'une page est conforme si elle atteint les objectifs recommandés au 75e percentile pour toutes les métriques Core Web Vitals. Si l'INP n'est pas présent pour les pages sans interactions, seuls le LCP et le CLS doivent être validés.
Différences entre les métriques selon les navigateurs
CrUX ne mesure que les navigateurs Chrome. Vous pouvez consulter les journaux des modifications des signaux Web essentiels pour voir comment ils évoluent avec chaque version de Chrome.
En revanche, les solutions RUM effectuent des mesures à partir d'une plus grande variété 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 non basés sur Chromium, les différences peuvent être plus prononcées. Les métriques basées sur l'affichage, comme le LCP, l'INP et le FCP, sont par exemple disponibles dans Safari et Firefox, mais sont mesurées différemment. Cela peut entraîner des écarts importants dans les temps indiqués. Comme indiqué précédemment, si vous souhaitez comparer les données RUM à celles de CrUX, il est préférable de filtrer uniquement les utilisateurs de Chrome pour permettre une comparaison à l'identique.
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 potentielles entre les valeurs rapportées à l'aide de ces API. Le moment exact où la métrique est mesurée (au chargement de page ou tout au long de son cycle de vie) 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 les mêmes API de navigateur pour obtenir les données, ce qui peut prêter à confusion.
Le Largest Contentful Paint (LCP) est une métrique de chargement de page. L'API Web peut signaler un certain nombre d'éléments LCP si des éléments plus volumineux sont chargés après l'affichage initial. L'élément LCP final est celui qui s'affiche lorsque la page a fini de se charger ou que l'utilisateur interagit avec elle. Par conséquent, des différences peuvent survenir 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 avec un lien d'ancrage plus bas dans le document, ou de la même manière avec un lien profond vers une application monopage (SPA) (nous y reviendrons plus tard), l'élément LCP peut être différent.
Ne partez pas du principe que les timings LCP fournis dans CrUX ou RUM sont basés sur le même élément que les outils de laboratoire. Alors que CrUX vous donne la valeur LCP globale par page ou par origine, RUM peut la segmenter davantage pour identifier les sessions individuelles présentant des problèmes de LCP.
La métrique Cumulative Layout Shift (CLS) est mesurée pendant toute la durée de vie de la page. Par conséquent, le CLS initial au chargement de page peut ne pas être représentatif des pages qui entraînent des décalages plus importants 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 en prenant la valeur CLS une fois que l'utilisateur a terminé d'utiliser la page.
La métrique de réactivité Interaction to Next Paint (INP) nécessite de mesurer une entrée et observe toutes les interactions (clic, appui et commandes au clavier) tout au long de la durée de vie de la page, de la même manière que le CLS. Par conséquent, la valeur de 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 sur les Core Web Vitals et les mesurera pendant toute la durée de vie de la page. Pour diverses raisons, de nombreux fournisseurs de RUM choisissent plutôt de mesurer ces métriques après le chargement de la page ou à un autre moment (par exemple, lorsqu'un utilisateur clique sur un incitation à l'action clé).
Il est important de comprendre quand les Core Web Vitals sont mesurés par votre fournisseur de RUM lorsque vous constatez des écarts inexpliqués entre les deux sources de données.
Applications monopages
Les applications monopages (SPA) fonctionnent en mettant à jour le contenu de la page actuelle, plutôt qu'en effectuant des navigations réelles au niveau du navigateur. Cela signifie que le navigateur ne les considère pas comme des navigations sur les pages, 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 sur les pages. Nous travaillons actuellement à la résolution de ce problème. Pour en savoir plus, consultez l'article Measuring soft navigations (Mesurer les 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", cela entraînera des différences avec CrUX, car les API sous-jacentes ne sont pas compatibles avec de nombreuses métriques.
Différences entre CrUX et l'API Web
Outre les différences concernant quelles vues de page 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 entre les données CrUX et RUM. Certaines sont dues aux limites des API Web utilisées pour mesurer les métriques, et d'autres sont dues 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 back/forward
CrUX considère les restaurations du cache back/forward (ou bfcache) comme des navigations sur les pages, même si elles n'entraînent pas un chargement de page classique. Comme les API Web ne les traitent pas comme un chargement de page, les solutions RUM doivent prendre des mesures supplémentaires pour que ces pages soient comptabilisées si elles veulent correspondre à CrUX. Ces chargements de page sont considérablement plus rapides et peuvent améliorer les performances globales d'un site. Ne pas les inclure peut donc entraîner une dégradation des métriques de performances globales des pages. Consultez votre solution RUM pour savoir si elle gère les pages restaurées à partir du bfcache.
iFrame
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 celles de même origine). Cela signifie que les métriques de performances du contenu de ces iFrames ne peuvent être mesurées que par l'iFrame elle-même, et non par les API Web de la page d'encadrement. Si le contenu de l'iframe inclut l'élément LCP ou un contenu qui a un impact sur le CLS ou l'INP rencontré par l'utilisateur, il ne sera pas disponible pour les solutions RUM (y compris la bibliothèque JavaScript Google web-vitals).
Toutefois, le rapport CrUX, qui est mesuré par le navigateur Chrome lui-même plutôt que par le code JavaScript de la page, n'est pas soumis à ces limites et mesure donc les métriques dans les iFrames lors de la création de rapports sur les Core Web Vitals. Cela reflète plus précisément l'expérience de l'utilisateur, mais peut être une autre raison des différences pour les sites utilisant 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'intégration de <video>. Le premier frame peint d'un élément <video> en lecture automatique peut être considéré comme un candidat LCP, mais les intégrations de 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 de <iframe>, contrairement aux solutions RUM.
Ressources interorigines
Les contenus multimédias LCP diffusés à partir d'autres domaines peuvent ne pas indiquer le 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 temporelles. Cela revient au temps de chargement de la ressource, mais cela peut être très différent du moment où le contenu a été réellement peint.
Cela peut conduire à 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 n'apparaît ainsi qu'en raison de cette restriction de sécurité.
Ce problème a été résolu fin 2024, et un délai d'affichage légèrement plus grossier est disponible à partir de Chrome 133, même lorsque Timing-Allow-Origin n'est pas fourni.
Là encore, CrUX fournit les données de délai d'affichage pour les Core Web Vitals. Il est conseillé aux sites de limiter le contenu interorigine qui a un impact sur les métriques Core Web Vitals et d'activer l'en-tête TAO lorsque cela est possible s'ils souhaitent mesurer ces métriques plus précisément. D'autres ressources interorigines 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 des API Web. Toutefois, elles ne sont pas signalées par CrUX, car elles fournissent des délais qui ne sont pas cohérents avec l'expérience utilisateur. Les solutions RUM doivent également envisager d'ignorer ces vues, ou au moins d'expliquer comment elles sont traitées.
Alors, 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 de différences dans la méthodologie utilisée par chacune, soit en raison des utilisateurs et des pages vues inclus ou exclus. Idéalement, les deux ensembles de données doivent être représentatifs des performances de votre site pour être utiles, mais les raisons fournies doivent expliquer pourquoi il est très peu probable d'obtenir exactement les mêmes chiffres dans chacun d'eux.
Lorsque les différences sont minimes (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 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 être plus proches de celles du CrUX (en ne prenant en compte que les utilisateurs de Chrome, sur ordinateur ou mobile, avec des valeurs au 75e centile sur 28 jours) afin de réduire ces différences ?
Si c'est le cas, et que vous pouvez obtenir des données plus proches, vous devez tout de même vous demander pourquoi vous constatez ces différences dans les données globales et ce que cela signifie. Les utilisateurs d'autres navigateurs que 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 prioriser ?
Si les utilisateurs d'autres navigateurs obtiennent des résultats différents, vous pouvez utiliser ces informations précieuses fournies par la MUR pour optimiser différemment. Par exemple, certaines API ne sont pas disponibles sur certains navigateurs, mais vous pouvez envisager des alternatives pour les navigateurs non compatibles afin d'améliorer également l'expérience utilisateur. Vous pouvez également proposer 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 tenir compte de 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 extrêmement utiles pour comprendre l'expérience utilisateur de 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'approfondir les informations fournies par CrUX à un niveau global en segmentant votre trafic. Vous pourrez ainsi identifier si des zones particulières de votre site ou de votre base d'utilisateurs nécessitent une attention particulière.
Il est souvent plus important d'examiner les tendances pour vérifier que vos améliorations ont les effets positifs attendus que de s'assurer que chaque chiffre correspond exactement entre les deux sources de données. Comme indiqué précédemment, le RUM vous permet d'examiner différentes périodes pour avoir un aperçu de vos scores CrUX sur 28 jours. Toutefois, l'examen de périodes trop courtes peut entraîner des données bruitées, d'où l'utilisation de 28 jours par CrUX.
Il n'y a souvent pas de "bonne" ou de "mauvaise" réponse dans ces différentes métriques. Elles offrent simplement un point de vue différent sur vos utilisateurs et sur la façon dont ils perçoivent votre site. Tant que vous comprenez pourquoi ces différences se produisent et comment elles peuvent influencer votre prise de décision, vous pouvez mieux répondre aux besoins des visiteurs de votre site.