CrUX
Le jeu de données d’expérience réelle de Chrome : qui y entre, sur quelle fenêtre, et pourquoi une page reste absente.
CrUX, ou Chrome User Experience Report, est le jeu de données public des expériences réelles mesurées chez les utilisateurs de Chrome. Google y agrège les mesures de chargement, de réactivité et de stabilité visuelle, page par page et origine par origine, sur une fenêtre glissante de 28 jours. C’est la source de terrain des Core Web Vitals, par opposition aux mesures de laboratoire de Lighthouse.
D’où viennent les données de CrUX ?
Des navigateurs Chrome de visiteurs réels, sous quatre conditions cumulatives. La documentation Chrome for Developers les énumère : l’utilisateur doit avoir activé l’envoi des statistiques d’utilisation, synchroniser son historique de navigation, ne pas avoir défini de phrase secrète de synchronisation, et se trouver sur une plateforme prise en charge. Ces plateformes sont Chrome pour Windows, macOS, ChromeOS et Linux, ainsi que Chrome pour Android, onglets personnalisés et WebAPK compris. Chrome sur iOS, les applications Android qui embarquent une WebView et les autres navigateurs Chromium, Microsoft Edge inclus, sont exclus. Google ne publie pas la proportion d’utilisateurs qui remplissent ces critères, ce qui interdit de convertir un chiffre CrUX en volume de trafic.
Quelles métriques CrUX publie-t-il ?
Les trois Core Web Vitals, plus une série de métriques complémentaires. Google Search Central fixe les seuils de bonne expérience : un LCP dans les 2,5 premières secondes, un INP inférieur à 200 millisecondes, un CLS inférieur à 0,1. CrUX ne renvoie pas une valeur unique mais une distribution : un histogramme à trois classes et un percentile. Le percentile retenu est le 75e, noté p75 dans l’API. Sa lecture exacte est donnée par la documentation : au moins 75 % des chargements de page ont été mesurés avec une valeur inférieure ou égale à celle affichée. Cette valeur est dérivée statistiquement et ne correspond pas forcément à une mesure vécue par un visiteur précis.
Pourquoi une page n’apparaît-elle pas dans CrUX ?
Deux conditions gouvernent l’entrée d’une URL dans le jeu de données. La première est la découvrabilité publique, évaluée par Chrome avec les mêmes critères d’indexabilité que les moteurs de recherche : une page servie avec un code HTTP autre que 200 après redirections, un en-tête X-Robots-Tag noindex ou une balise meta robots noindex la disqualifie. La seconde est la popularité : la page doit dépasser un nombre minimum de visiteurs. Google ne divulgue pas ce seuil et précise seulement qu’il est identique pour les pages et pour les origines. Une origine peut donc figurer dans CrUX pendant que la plupart de ses pages en sont absentes, puisque les expériences de toutes les pages d’une origine découvrable comptent au niveau de l’origine.
Où consulter les données CrUX ?
Quatre points d’accès officiels servent la même source. L’API CrUX renvoie les données page et origine à la demande, avec un retard d’environ deux jours sur la date du jour, le temps que la journée soit complète et traitée, et sur un fuseau fixé à l’heure du Pacifique sans changement d’heure d’été. PageSpeed Insights affiche ces mêmes chiffres de terrain à côté de son audit de laboratoire. Le rapport Core Web Vitals de Google Search Console les regroupe par groupes d’URL similaires. Enfin BigQuery publie un jeu mensuel, sous la table chrome-ux-report.all, mis en ligne le deuxième mardi du mois suivant.
| Accès | Granularité | Fraîcheur documentée |
|---|---|---|
| API CrUX | Page et origine | Fenêtre de 28 jours, environ 2 jours de retard |
| PageSpeed Insights | Page et origine | Fenêtre de 28 jours |
| BigQuery | Origine, par pays et appareil | Jeu mensuel, deuxième mardi du mois suivant |
Sur quelle période CrUX agrège-t-il ?
Sur 28 jours glissants, et l’API l’annonce toujours ainsi. La documentation pose une nuance que les tableaux de bord ignorent : la période de collecte affichée vaut 28 jours même quand les données ne couvrent pas 28 jours pleins, par exemple pour une page mise en ligne il y a moins d’un mois. La période de collecte décrit l’intervalle d’agrégation, pas l’intervalle réellement représenté. Conséquence pratique en audit : un correctif de performance déployé un lundi ne se lit pleinement dans CrUX qu’après un mois, et son effet apparaît d’abord dilué dans la moyenne des semaines précédentes.
Comment lire une évolution CrUX sans se tromper ?
En sachant que deux points hebdomadaires consécutifs partagent trois semaines de données sur quatre. La documentation de l’API CrUX History l’écrit noir sur blanc : chaque période de collecte agrège les 28 jours qui la précèdent, les périodes se succèdent chaque semaine, elles se chevauchent donc. Google les compare lui-même à une moyenne mobile, avec trois semaines communes à deux périodes voisines et une seule semaine différente. La conséquence est massive pour qui suit une courbe : une variation d’une semaine à l’autre ne décrit qu’un quart de données nouvelles. Un correctif ne produit un écart franc qu’après quatre périodes, et une secousse isolée sur un point unique relève presque toujours du bruit.
Le rythme de publication diffère aussi d’un outil à l’autre, pour la même source. L’API CrUX History est mise à jour chaque lundi, contient les données jusqu’au samedi précédent et couvre les 40 dernières semaines, dont 25 périodes renvoyées par défaut, un nombre réglable de 1 à 40. L’API CrUX classique et PageSpeed Insights servent une moyenne de 28 jours actualisée quotidiennement, sans historique. Le rapport Core Web Vitals de Google Search Console remonte à trois mois, par groupe de pages. BigQuery publie un jeu mensuel qui remonte à 2017, au niveau de l’origine seulement. Comparer un chiffre PageSpeed Insights du jour à un point BigQuery du mois dernier revient donc à comparer deux fenêtres différentes de la même mesure.
Le CrUX Dashboard, tableau de bord Looker Studio adossé aux tables BigQuery, est déclaré obsolète par Google. Sa documentation renvoie vers CrUX Vis, fondé sur l’API CrUX History, avec quatre avantages annoncés : chargement plus rapide, mises à jour hebdomadaires au lieu de mensuelles, données au niveau de l’origine et de l’URL quand elles existent, et des métriques absentes de l’ancien tableau de bord.
Quel rapport entre CrUX et le classement Google ?
CrUX fournit la mesure, les systèmes de classement consomment le signal. Google Search Central recommande aux propriétaires de sites d’obtenir de bons Core Web Vitals pour réussir dans la recherche, en alignant cette recommandation sur ce que ses systèmes de classement cherchent à récompenser au titre de l’expérience de page. La documentation n’annonce ni pondération ni bonus chiffré. Un site sans données CrUX n’est pas exclu de la recherche : il est simplement invisible pour cette mesure, et un audit doit alors basculer sur des mesures de laboratoire ou sur sa propre collecte côté client.
Quelles limites CrUX impose-t-il à la lecture ?
Quatre traitements documentés modifient ce que l’analyste croit lire. Les paramètres de requête et les fragments d’URL sont retirés avant agrégation, si bien que deux pages distinctes servies sous le même chemin avec des paramètres différents se retrouvent fusionnées. Les iframes ne sont jamais rapportés séparément, leurs mesures remontent à la page de premier niveau qui les héberge. Une origine ou une page dont plus de 20 % du trafic total est écarté pour cause de combinaisons de dimensions inéligibles disparaît entièrement du jeu de données. Enfin Google applique un bruit aléatoire, appelé fuzzing, pour empêcher la rétro-ingénierie des volumes de trafic, sans altérer l’exactitude des statistiques agrégées. Les applications monopages ajoutent une limite propre : leurs transitions de route en JavaScript ne créent pas de nouvelle vue de page pour les API du navigateur, et l’ensemble de la session reste attribué à la vue initiale.
Erreur fréquente observée en audit
Erreur observée. L’absence d’une page dans CrUX est lue comme une panne de mesure, et l’audit part chercher un problème de collecte qui n’existe pas. La documentation donne pourtant deux causes ordinaires et testables en quelques minutes : la page n’est pas découvrable publiquement, ou elle n’atteint pas le seuil de visiteurs. Le premier réflexe consiste donc à vérifier le code HTTP renvoyé après redirections, l’en-tête X-Robots-Tag et la balise meta robots, avant toute hypothèse sur la performance elle-même. Un second piège suit de près : comparer une valeur de laboratoire issue de Lighthouse à un p75 de terrain revient à comparer un chargement simulé à la distribution d’un mois de visites réelles.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Chrome for Developers, CrUX methodology : éligibilité, filtrage et fuzzing
- 2Chrome for Developers, CrUX API : percentiles, période de collecte et fraîcheur
- 3Chrome for Developers, CrUX on BigQuery : publication mensuelle
- 4Google Search Central, Understanding Core Web Vitals and Google search results · mise à jour du 10 décembre 2025
- 5Chrome for Developers, CrUX Tools : fréquence et profondeur d’historique par outil · mise à jour du 9 septembre 2025
- 6Chrome for Developers, CrUX History API : périodes de collecte et chevauchement · mise à jour du 11 avril 2025
Questions fréquentes
Que signifie CrUX ?−
CrUX est l’abréviation de Chrome User Experience Report, le jeu de données public dans lequel Google agrège les expériences réelles des utilisateurs de Chrome.
Sur combien de jours porte une mesure CrUX ?+
Sur 28 jours glissants. L’API annonce toujours cette période, même lorsque la page dispose de moins de 28 jours de données réelles.
Pourquoi mon site n’a-t-il aucune donnée CrUX ?+
Parce qu’il ne remplit pas l’une des deux conditions d’entrée : être découvrable publiquement, avec un code HTTP 200 et sans règle noindex, et dépasser un nombre minimum de visiteurs que Google ne publie pas.
Le navigateur Edge alimente-t-il CrUX ?+
Non. Chrome for Developers exclut explicitement les autres navigateurs Chromium, dont Microsoft Edge, ainsi que Chrome sur iOS et les WebView Android.
Quelle différence entre CrUX et Lighthouse ?+
CrUX rapporte des mesures de terrain issues de visiteurs réels sur 28 jours. Lighthouse exécute un chargement simulé en laboratoire, à un instant donné et dans des conditions imposées.
Que veut dire le p75 affiché par CrUX ?+
Qu’au moins 75 % des chargements de page ont été mesurés avec une valeur inférieure ou égale à celle affichée. Cette valeur est dérivée statistiquement, elle ne décrit pas l’expérience d’un visiteur identifié.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).