Le tableau RUM annonce un LCP mobile au 75e percentile de 2,2 secondes. Le rapport CrUX affiche pourtant 3,1 secondes pour la même origine et la direction demande quel outil se trompe.
Le problème n’est souvent pas une erreur de calcul, mais une population différente qui crée un risque de mauvaise priorité. Le premier signal faible est un percentile stable malgré une release importante ; le second signal faible est un écart qui disparaît sur quelques URL fréquentées.
Le vrai enjeu consiste à rendre deux observations comparables avant de chercher une cause. Vous allez comprendre comment aligner fenêtre, périmètre et définition, puis utiliser template, appareil, pays et navigation pour isoler la cohorte responsable sans transformer une corrélation en diagnostic.
Notre accompagnement SEO technique relie mesure terrain, architecture front et priorité business. Cette lecture distingue aussi l’expérience utilisateur du crawl, de l’indexation et du comportement de Googlebot.
Dans quels cas la comparaison entre RUM et CrUX devient utile
La comparaison devient utile lorsqu’un indicateur public change sans cause visible, lorsqu’une correction RUM ne remonte pas encore dans CrUX ou lorsque deux équipes prennent des décisions opposées depuis des percentiles différents.
Distinguer divergence normale et anomalie de collecte
Deux sources terrain n’observent pas forcément les mêmes utilisateurs, navigateurs, pages ni dates. Un écart cohérent avec ces différences est informatif ; un saut brutal limité à la collecte RUM peut signaler une instrumentation cassée.
Par exemple, une CMP qui bloque le script de mesure dans certains pays retire précisément une partie des sessions lentes. CrUX continue de les agréger si elles sont éligibles, tandis que le RUM interne s’améliore artificiellement.
Choisir la source selon la question
CrUX répond à la performance observée par une population Chrome éligible sur une origine ou une URL publique. Le RUM propriétaire peut répondre à la version, au template, au parcours et à l’attribution technique si ces dimensions sont collectées correctement.
Contre-intuitivement, la source la plus détaillée n’est pas automatiquement la plus représentative. Une instrumentation riche mais absente de 35 % des sessions critiques doit être corrigée avant de devenir l’arbitre du budget performance.
Définir le périmètre de chaque source avant tout rapprochement
CrUX et RUM sont deux données terrain, mais leurs contrats diffèrent. Documenter inclusion, exclusion, agrégation et rétention évite d’attribuer un écart de population au code de la page.
Lire CrUX comme une agrégation publique filtrée
CrUX recueille des expériences d’utilisateurs Chrome ayant activé la synchronisation de l’historique, sans phrase secrète, et autorisé les statistiques d’usage. Les pages et combinaisons de dimensions doivent aussi satisfaire des critères d’éligibilité et de popularité.
L’API présente une moyenne glissante de vingt-huit jours, mise à jour quotidiennement. Une valeur d’origine mélange toutes les pages éligibles de cette origine ; une valeur URL ne décrit que cette adresse lorsque le volume suffit.
Décrire explicitement le contrat du RUM
Le RUM précise navigateurs supportés, consentement, taux d’échantillonnage, robots exclus, applications embarquées, environnements, déduplication et expiration. Sans ce dictionnaire, un dashboard donne une précision visuelle supérieure à sa précision statistique.
Les entrées sont événement, contexte et version ; les sorties sont métrique et attribution pseudonymisées. La responsabilité couvre consentement, qualité, journalisation et monitoring, avec seuil d’absence puis repli vers une collecte minimale lorsque le pipeline analytique échoue.
Aligner URL, période, appareil et définition de la métrique
La comparaison commence par une fiche d’alignement. Elle empêche de rapprocher une origine CrUX sur vingt-huit jours d’un RUM filtré sur sept jours et trois pages d’acquisition.
Construire une cohorte miroir
La cohorte RUM retient les mêmes dates, le même protocole, le même hôte, la même URL ou origine et le même facteur de forme. Elle applique la même unité et calcule la distribution par expérience de page, pas par utilisateur moyen.
Pour une URL canonique avec paramètres, la règle de normalisation est explicite. CrUX peut distinguer des URL que le RUM regroupe, ou inversement ; une collision de clé transforme alors plusieurs distributions en moyenne artificielle.
Vérifier la bibliothèque et le moment d’envoi
Le RUM utilise une implémentation alignée sur les définitions Web Vitals et conserve identifiant de métrique, valeur finale, delta et type de navigation. INP peut ne jamais être reporté si l’utilisateur n’interagit pas avec la page.
Une métrique envoyée seulement au chargement sous-estime CLS tardif et INP. Le transport doit accepter la fin de page, les changements de visibilité et les restaurations depuis le cache de navigation sans dupliquer une même instance.
Segmenter par template plutôt que poursuivre chaque URL
Une URL montre un symptôme ; le template rapproche le symptôme du code partagé. Cette dimension devient essentielle lorsque CrUX manque de volume au niveau page ou lorsque des milliers d’URL utilisent les mêmes composants.
Attribuer le template côté serveur
Le HTML expose un identifiant stable comme product-detail-v4, category-list-v2 ou editorial-longform-v3. Le collecteur l’envoie avec la métrique, que le rendu repose sur SSR, SSG ou ISR, sans déduire le type depuis une expression régulière fragile.
La version de template reste distincte de la version globale de l’application. Deux pages peuvent recevoir le même déploiement mais des composants différents à cause d’un feature flag ou d’une expérience.
Comparer distribution, trafic et valeur business
Le tableau montre P50, P75, P90, taux bon/à améliorer/mauvais, nombre d’observations et poids de trafic. Une médiane correcte ne doit pas masquer une longue traîne qui concerne les sessions de conversion.
Un template représentant 4 % des vues mais 38 % du chiffre d’affaires peut précéder une homepage plus lente. La priorité relie amplitude, population exposée, valeur et capacité à corriger un composant commun.
Lire appareil, navigateur et capacité matérielle sans surinterpréter
Le facteur de forme CrUX distingue téléphone, ordinateur et tablette. Le RUM peut enrichir la lecture avec navigateur, mémoire indicative, concurrence du thread principal et qualité réseau, sous réserve de disponibilité et de respect de la vie privée.
Séparer le coût CPU du coût réseau
Un LCP lent avec TTFB stable et temps de rendu croissant sur appareils modestes pointe vers CSS, JavaScript ou décodage d’image. Un TTFB et un temps de chargement de ressource élevés orientent plutôt vers origine, CDN ou réseau.
La mise en place d’un monitoring RUM Core Web Vitals fournit le socle de collecte. La présente segmentation ajoute le contrat de comparaison nécessaire pour ne pas mélanger familles d’appareils et causes techniques.
Garder un groupe témoin assez large
Découper par navigateur, version, appareil et réseau crée vite des cellules minuscules. Le diagnostic commence par appareil, puis ajoute une dimension seulement lorsque le volume et l’hypothèse justifient cette finesse.
Si le P75 mobile se dégrade de 420 millisecondes sur au moins dix mille observations, puis que 80 % de l’écart se concentre sur un navigateur, l’analyse descend. Sinon elle conserve la cohorte globale et collecte davantage.
Interpréter pays, réseau et infrastructure comme un faisceau
Le pays n’est pas une cause technique. Il sert de proxy imparfait pour distance au point de présence, opérateurs, parc matériel, cache, consentement, poids des contenus et variantes commerciales.
Comparer une même version sur plusieurs zones
Le RUM associe pays grossier, région d’infrastructure, cache hit, TTFB et versions de ressource. Les données sont agrégées à un niveau qui évite toute identification individuelle.
Si le LCP augmente seulement au Brésil, il faut vérifier TTFB, héros, CDN, cache, redirections et consentement avant de conclure à un réseau lent. Une variante d’image locale peut suffire à expliquer la distribution.
Comprendre les limites de la dimension publique
CrUX applique des seuils d’éligibilité aux combinaisons de dimensions ; une origine peut exister au niveau global sans exposer chaque pays. L’absence de donnée publique ne signifie donc ni absence de trafic ni bonne performance.
Le RUM interne peut combler ce manque, mais son consentement varie parfois selon la juridiction. La fiche de cohorte indique alors taux de couverture par pays afin que la comparaison ne confonde performance et politique de collecte.
Distinguer navigation initiale, rechargement, retour et prérendu
Deux expériences de la même URL peuvent mobiliser des chemins radicalement différents. Cache HTTP, bfcache, Service Worker et prérendu modifient temps de réponse, ressources et travail JavaScript.
Conserver le type de navigation avec chaque métrique
La bibliothèque web-vitals distingue notamment navigate, reload, back-forward, restauration bfcache, prerender et restore selon les capacités du navigateur. La cohorte « premier arrivant SEO » ne doit pas mélanger une restauration instantanée.
Un gain global peut provenir d’une hausse des retours bfcache sans amélioration du chargement initial. Ce gain utilisateur reste réel, mais il ne valide pas une correction annoncée sur le héros ou le TTFB.
Mesurer les transitions SPA sans les appeler chargements de page
Les navigations douces d’une SPA exigent une instrumentation spécifique et ne se confondent pas automatiquement avec les expériences de page CrUX. Le contrat nomme route virtuelle, point de départ et condition de contenu prêt.
La segmentation peut suivre réactivité et stabilité sur ces transitions, mais la comparaison publique reste attachée aux définitions disponibles. L’équipe évite ainsi de fabriquer un LCP interne sémantiquement différent.
Attribuer LCP, INP et CLS à une cause corrigeable
Une segmentation localise la population ; l’attribution localise le mécanisme. La build d’attribution de web-vitals ajoute les éléments et phases utiles sans remplacer une trace de performance complète.
Décomposer le LCP par phase
Le RUM conserve TTFB, délai avant chargement de la ressource, durée de chargement et délai de rendu, ainsi que l’élément LCP normalisé. La phase dominante oriente vers serveur, découverte, transfert ou thread principal.
Un héros identique peut être lent sur une variante parce que son URL arrive dans le DOM après hydratation. L’audit du contrat de rendu JavaScript aide à rapprocher cette attribution du HTML effectivement produit.
Relier INP et CLS au composant partagé
Pour INP, le collecteur garde cible, type d’interaction et décomposition entre input delay, traitement et presentation delay. Pour CLS, il garde plus grand shift, cible et sources probables sans enregistrer de contenu sensible.
Les sélecteurs sont normalisés vers des identifiants de composants stables. Une classe CSS générée ou une saisie utilisateur ne doit jamais devenir une dimension à forte cardinalité ni une fuite de données.
Protéger la lecture contre petits échantillons et distributions instables
Un percentile n’est pas une valeur observée sur un utilisateur type. Il dépend de la distribution et devient instable lorsque la cohorte contient trop peu de mesures ou change de composition.
Afficher volume, couverture et intervalle avec la valeur
Chaque cellule montre nombre d’expériences, part des sessions éligibles, taux de collecte et intervalle obtenu par bootstrap ou méthode documentée. Un P75 sans ces repères ne permet pas de comparer deux templates.
Par exemple, un gain de 120 millisecondes avec un intervalle de plus ou moins 260 reste indéterminé. L’équipe attend plus de trafic ou agrège une dimension, plutôt que de déclarer une victoire.
Contrôler la composition avant et après
Une campagne peut doubler la part de mobile international et dégrader le percentile global sans changement du site. Le tableau compare les poids de chaque strate avant de conclure à une régression technique.
Une standardisation simple recalcule les deux périodes avec les mêmes poids de template, appareil et pays. La valeur standardisée n’efface pas la réalité utilisateur ; elle sépare effet de composition et effet du produit.
Relier chaque cohorte aux versions et changements déployés
CrUX lisse vingt-huit jours, alors qu’un déploiement intervient à une heure précise. Le RUM sert de microscope temporel pour confirmer rapidement une rupture, puis CrUX valide sa diffusion dans la population publique.
Marquer release, feature flag et variante
Chaque mesure porte version front, version template et variante d’expérience. Les logs de QA et de CI relient ces identifiants aux composants, dates, cohortes exposées et responsables de correction.
Les entrées comprennent métrique et contexte de release ; les sorties comprennent alerte et cohorte suspecte. Le monitoring compare seuil et baseline, journalise l’hypothèse, puis déclenche repli ou rollback du flag si l’impact dépasse le contrat.
Utiliser une fenêtre assez courte sans confondre bruit et signal
Une alerte précoce peut employer moyenne robuste, ratio de mauvaises expériences ou changement de distribution, avec un minimum d’observations. Elle compare une cohorte stable à sa propre baseline horaire et hebdomadaire.
Si le P75 LCP d’un template progresse de 18 % pendant trente minutes sur plus de cinq mille vues, alors l’équipe inspecte la release. Le seuil est illustratif et doit être calibré sur trafic, variance et risque business.
Utiliser le laboratoire après le terrain, pour reproduire une hypothèse
Le laboratoire ne mesure pas une population réelle. Il fournit un environnement contrôlé pour reproduire le template, la ressource ou la tâche longue identifiée par le terrain.
Transformer une cohorte lente en scénario reproductible
Le test reprend URL, viewport, cache froid ou chaud, latence, CPU, compte, variante et parcours. Il capture waterfall, trace du thread principal, filmstrip et requêtes serveur pour relier le symptôme à un composant.
Une valeur Lighthouse différente du RUM n’invalide pas le terrain. Si le laboratoire reproduit le mécanisme sous une condition connue, il devient utile pour développer et tester le correctif.
Refermer la boucle sur les utilisateurs
Le correctif passe d’abord les budgets synthétiques et la non-régression fonctionnelle, puis une exposition progressive. Le RUM vérifie la cohorte cible ; CrUX confirme ensuite la tendance lorsque sa fenêtre glissante intègre suffisamment de trafic corrigé.
Cette séquence évite deux erreurs symétriques : refuser un gain parce qu’il n’apparaît pas immédiatement dans CrUX, ou généraliser un meilleur score labo sans effet terrain.
Erreurs fréquentes qui produisent une comparaison trompeuse
Les erreurs les plus courantes alignent des nombres visuellement similaires mais sémantiquement différents. Elles produisent des tickets précis sur la mauvaise population ou la mauvaise cause.
Refuser huit raccourcis d’analyse
- Comparer origine et template : l’origine CrUX mélange des pages dont le trafic et les composants peuvent avoir évolué différemment.
- Comparer 7 et 28 jours : une release récente domine le RUM court mais reste diluée dans la fenêtre glissante publique.
- Mélanger mobile et desktop : parc matériel, réseau, viewport et comportements de navigation modifient fortement les distributions de performance.
- Confondre absence et zéro : une métrique non reportée, notamment INP sans interaction, ne doit jamais devenir une excellente valeur.
- Ignorer le consentement : le RUM peut exclure des pays, navigateurs ou visiteurs dont la performance diffère du reste de la population.
- Découper sans volume : une cellule de quelques dizaines d’observations produit des percentiles instables qui changent sans cause technique.
- Appeler le labo terrain : un run contrôlé aide au diagnostic, mais ne mesure ni la distribution des appareils ni les parcours réels.
- Prendre corrélation pour cause : un pays ou un navigateur localise une cohorte ; waterfall, attribution et trace doivent encore prouver le mécanisme.
La comparaison est recevable seulement si la fiche d’alignement est complète. Une différence inexpliquée reste une question de mesure, pas une autorisation de modifier un template au hasard.
Matrice de décision pour chaque écart entre RUM et CrUX
La matrice sépare les écarts attendus, les défauts de collecte et les régressions plausibles. Elle empêche qu’une différence de source devienne automatiquement une dette front.
Choisir l’action depuis la preuve disponible
- À valider : périmètre, fenêtre, appareil et métrique sont alignés, puis les distributions convergent dans leur marge d’incertitude.
- À différer : le volume reste insuffisant ou la fenêtre CrUX n’intègre pas encore assez de trafic post-correctif pour conclure.
- À corriger : consentement, déduplication, normalisation d’URL, timing d’envoi ou attribution retire une partie identifiable des expériences RUM.
- À bloquer : une régression importante touche un template business, se reproduit en laboratoire et dépasse le seuil terrain convenu.
Chaque ligne conserve fait, hypothèse, segment, volume, intervalle, prochaine mesure et responsable. Le statut change seulement lorsque la nouvelle preuve répond à la cause supposée, pas lorsqu’un percentile redevient vert isolément.
Cas concret : un LCP mobile contradictoire après refonte des fiches
Après une refonte, le RUM global mobile passe de 2,8 à 2,3 secondes au P75. Trois semaines plus tard, CrUX origine reste à 3,0 secondes et le statut public ne progresse pas.
Aligner avant d’attribuer
La cohorte miroir montre que le RUM exclut deux pays soumis à un consentement différent et que 46 % de son trafic vient des fiches produit corrigées. CrUX origine agrège aussi catégories, recherche et pages éditoriales inchangées.
Sur les URL de fiches disposant d’un niveau public suffisant, la tendance converge. Le problème n’est donc pas un correctif inefficace, mais une couverture trop étroite pour modifier l’origine entière.
Trouver la prochaine priorité dans les segments
Le RUM par template révèle un P75 de 3,8 secondes sur les catégories mobiles internationales. L’attribution LCP pointe un délai de découverte du héros injecté après une requête de personnalisation.
Le laboratoire reproduit le retard avec cache froid et variante internationale. L’équipe rend le héros découvrable dans le HTML, expose progressivement la correction et suit cette cohorte sans réécrire la conclusion sur les fiches déjà améliorées.
Plan d’action : déployer un protocole de lecture en six semaines
La trajectoire commence par le contrat de données, pas par un nouveau dashboard. Chaque semaine ferme une ambiguïté entre population mesurée, segment explicatif et correction technique.
- Semaine 1 : documenter CrUX, RUM, consentement, navigateurs, échantillonnage, URL, rétention, déduplication, métriques et propriétaires de qualité des données.
- Semaine 2 : ajouter template, version, appareil, pays agrégé, navigation et attribution avec cardinalité bornée et revue de confidentialité.
- Semaine 3 : construire cohortes miroir URL et origine sur vingt-huit jours, comparer couverture, distribution, P75 et incertitude par facteur de forme.
- Semaine 4 : identifier les templates et pays qui expliquent l’écart, puis relier LCP, INP ou CLS aux phases et composants partagés.
- Semaine 5 : reproduire les deux hypothèses prioritaires en laboratoire avec leurs conditions réelles, livrer une correction derrière un flag et surveiller.
- Semaine 6 : confirmer le gain RUM sur la cohorte cible, contrôler les autres segments, puis planifier la lecture CrUX après renouvellement suffisant de sa fenêtre.
Portes d’acceptation du dispositif
- Périmètre explicable : chaque différence d’utilisateur, navigateur, page, date et consentement est documentée avant interprétation des valeurs.
- Segments actionnables : template, version, appareil, pays et navigation restent assez peu nombreux pour produire des cohortes stables et reliées au code.
- Cause reproductible : l’attribution terrain conduit à un scénario laboratoire qui fait varier le même composant dans la direction attendue.
- Gain refermé : la cohorte corrigée progresse sans dégrader les autres, puis la tendance publique est relue selon sa fenêtre réelle.
Ces quatre portes sont revues ensemble : une collecte parfaitement alignée ne suffit pas si les segments restent impossibles à relier à un composant, une release et une action de correction.
À différer : une optimisation fondée sur un segment dont la couverture, le consentement ou le volume rendent la distribution instable. L’équipe conserve alors l’hypothèse et attend une fenêtre comparable au lieu de convertir l’incertitude en priorité.
Après livraison, la reprise vérifie d’abord la cohorte RUM exposée, puis les segments voisins et enfin CrUX selon sa fenêtre glissante. Un gain de laboratoire seul ne ferme jamais la décision.
Contenus complémentaires et sources officielles sur RUM, CrUX et Web Vitals
Les documents officiels suivants précisent population CrUX, fenêtre d’agrégation, différences avec un RUM propriétaire, type de navigation et données d’attribution disponibles pour le diagnostic technique.
La méthode d’attribution d’une régression à une release aide à tester le mécanisme après segmentation ; la preuve de parité du cache isole les écarts qui viennent plutôt d’une variante servie.
- Chrome for Developers — méthodologie CrUX documente éligibilité, popularité, agrégation origine ou page, dimensions filtrées et protection statistique.
- Chrome for Developers — API CrUX décrit identifiants, facteur de forme, histogrammes, moyenne glissante de vingt-huit jours et mise à jour quotidienne.
- web.dev — différences entre CrUX et RUM explique les écarts de population, navigateur, iframe, collecte et définition entre deux sources terrain.
- GoogleChrome — bibliothèque web-vitals expose identifiant, delta, type de navigation, build d’attribution, limites des API et exemples d’envoi vers une solution analytique.
Les seuils et segments internes restent des choix de gouvernance. Ils doivent être calibrés sur le trafic, la variance, la confidentialité et la valeur des parcours, puis révisés lorsque la collecte change.
Conclusion : comparer pour localiser, puis reproduire pour corriger
RUM et CrUX ne sont pas deux juges chargés de produire le même nombre. Ce sont deux observations terrain dont la valeur augmente lorsqu’on sait expliquer leur population, leur fenêtre et leur niveau d’agrégation.
L’alignement écarte les faux conflits ; la segmentation retrouve le template ou le parcours ; l’attribution formule une hypothèse ; le laboratoire la reproduit. La correction revient enfin au terrain pour mesurer l’effet sur les utilisateurs concernés.
Pour mettre en place cette boucle, notre accompagnement SEO technique relie collecte RUM, lecture CrUX, diagnostic front, tests reproductibles et validation post-déploiement afin que chaque priorité corresponde à une cohorte réelle et à une cause corrigeable.
