Guide du Chrome UX Report (CrUX)

En bref — CrUX rassemble des données de vitesse réelles provenant d’utilisateurs de Chrome. Google s’appuie sur ces données, et non sur le score de laboratoire produit par Lighthouse sur une seule machine, pour évaluer vos Core Web Vitals. Un score Lighthouse vert peut donc coexister avec un avertissement dans Search Console : les deux mesures n’observent pas la même chose.

Qu’est-ce que CrUX ?

Le Chrome User Experience Report, ou CrUX, est un jeu de données gratuit publié par Google. Il décrit l’expérience de personnes réelles, sur leurs appareils et réseaux réels. Au lieu de tester une page une seule fois en laboratoire, CrUX agrège les mesures d’un grand nombre d’utilisateurs de Chrome.

On parle de données de terrain, ou parfois de données d’utilisateurs réels. Elles s’opposent aux données de laboratoire, que Lighthouse produit en chargeant une page sur une machine de test contrôlée. Les deux sont utiles, mais Google utilise les données de terrain pour évaluer le site.

Pourquoi est-ce important ?

CrUX est le jeu de données officiel du programme Core Web Vitals. Les systèmes de classement de Google utilisent les signaux mesurés auprès d’utilisateurs réels, pas un score Lighthouse de laboratoire. Ne consulter que Lighthouse peut donc donner une vision trompeuse.

Vous avez probablement déjà consulté CrUX sans le savoir. Dans PageSpeed Insights, la section « Découvrez l’expérience de vos utilisateurs réels » vient de CrUX. Le rapport Core Web Vitals de Search Console repose lui aussi sur CrUX. Ce sont ces chiffres qui comptent.

L’erreur la plus fréquente

Un bon score Lighthouse ne garantit pas de bons Core Web Vitals. Lighthouse exécute un test unique sur un appareil simulé, avec un réseau limité et un cache vide. Vos visiteurs utilisent des téléphones et ordinateurs variés, des connexions rapides ou lentes et se trouvent plus ou moins loin. CrUX reflète cette diversité. Une page peut obtenir 95 dans Lighthouse et rester classée « Mauvaise » dans CrUX si la majorité des visiteurs mobiles subissent de mauvaises performances.

Autre surprise : toutes les pages ne figurent pas dans CrUX. Une URL doit recevoir assez de visites réelles pour être incluse. De nombreuses pages peu fréquentées n’ont aucune donnée CrUX ; les outils affichent alors les données du site entier, c’est-à-dire de l’origine, ou indiquent qu’aucune donnée de terrain n’est disponible.

Pour approfondir la fenêtre de 28 jours, le 75e percentile, la différence entre origine et URL ainsi que les moyens d’accès aux données, ouvrez l’onglet Avancé.

En bref — CrUX est le rapport officiel sur l’expérience des utilisateurs de Chrome : des données UX de terrain agrégées à partir d’utilisateurs admissibles, selon les critères d’activation des statistiques, de synchronisation et de plateforme pris en charge par Google. Ce jeu de données alimente les Core Web Vitals. Les résultats sont exprimés au 75e percentile sur une fenêtre d’agrégation glissante de 28 jours, pour l’origine comme pour l’URL. La couverture reste partielle : elle n’inclut ni tous les utilisateurs de Chrome ni tous les visiteurs, exclut Chrome sur iOS, Edge, Safari et Firefox, et exige un volume suffisant. Les URL peu fréquentées peuvent donc ne présenter aucune donnée ou seulement un repli vers l’origine. Six interfaces donnent actuellement accès à CrUX : PageSpeed Insights, Search Console, l’API CrUX, l’API History, BigQuery et CrUX Vis. Vérifiez la documentation actuelle, car les cadences et quotas évoluent. CrUX mesure le terrain ; Lighthouse mesure le laboratoire.

CrUX, couche de données de terrain des Core Web Vitals

Google le décrit clairement : “The Chrome User Experience Report … is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traduction) « Le Chrome User Experience Report est un jeu de données qui reflète la façon dont de vrais utilisateurs de Chrome vivent leur expérience sur des destinations populaires du Web. » Ce n’est pas un projet annexe : “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (traduction) « CrUX est le jeu de données Google du programme Web Vitals. Toutes les métriques Core Web Vitals centrées sur l’utilisateur y sont représentées. » Ces données sont “used by Google Search to inform the page experience ranking factor.” (traduction) « utilisées par Google Search pour alimenter le facteur de classement lié à l’expérience sur la page. »

Le bon modèle mental est donc le suivant : les Core Web Vitals sont les métriques ; CrUX est le jeu de données qui les contient. Lorsque Search évalue vos CWV, il consulte CrUX. Cette distinction résout l’essentiel de la confusion.

Comment CrUX collecte les données

CrUX repose sur de vrais utilisateurs de Chrome, mais seulement sur un sous-ensemble admissible, jamais sur tous les utilisateurs ni tous les visiteurs. Une expérience est agrégée si l’utilisateur remplit quatre critères : “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” (traduction) « Activer l’envoi des statistiques d’utilisation. Synchroniser l’historique du navigateur. Ne pas avoir défini de phrase secrète de synchronisation. Utiliser une plateforme prise en charge. »

La notion de « plateforme prise en charge » est déterminante. Sont inclus Chrome pour ordinateur sur Windows, macOS, ChromeOS et Linux, ainsi que Chrome sur Android, y compris Custom Tabs et WebAPK. Sont exclus Chrome sur iOS, les WebView Android et les “other Chromium browsers.” (traduction) « autres navigateurs basés sur Chromium. » En pratique, Microsoft Edge, Samsung Internet, Safari et Firefox ne figurent pas dans CrUX, pas plus que les navigateurs iOS, tous fondés sur WebKit.

C’est un angle mort à garder en tête. Sur un site marchand ou média dont l’audience utilise surtout iPhone et Safari, CrUX peut ne mesurer qu’une minorité des visiteurs réels. Les données ne sont pas fausses ; elles ne représentent simplement pas tout le monde.

Pourquoi certaines pages n’ont-elles pas de données CrUX ?

CrUX ne couvre pas toutes les pages. Google précise : “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” (traduction) « Toutes les origines et toutes les pages ne sont pas représentées. Des critères distincts s’appliquent aux origines et aux pages : elles doivent notamment être découvrables publiquement et recevoir assez de visiteurs pour constituer un jeu de données statistiquement significatif. » Le seuil exact de popularité n’est pas publié ; tout chiffre précis avancé ailleurs reste une estimation non officielle.

L’admissibilité des pages et celle des origines sont évaluées séparément. Une origine peut disposer d’un trafic admissible suffisant alors que nombre de ses pages n’en ont pas. C’est pourquoi un domaine peut afficher des données d’origine sans résultat pour une URL précise. Une absence n’est pas un score : elle signifie seulement que l’échantillon admissible est trop faible. Ce n’est ni zéro, ni une réussite, ni un échec.

Des exigences techniques s’appliquent aussi : après les redirections, la page doit renvoyer 200 et ne doit pas porter de directive noindex, dans l’en-tête ou la balise meta. Une règle des 20 % existe également : “origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.” (traduction) « les origines ou pages dont plus de 20 % du trafic total est exclu à cause de combinaisons de dimensions non admissibles sont entièrement retirées du jeu de données. »

J’ai mesuré la faiblesse de cette couverture. Dans mon étude sur les données Core Web Vitals, j’ai croisé CrUX avec un crawl Ahrefs de 43,66 millions de pages. Seules 5,21 millions d’entre elles, soit environ 11,9 %, possédaient au moins une métrique Core Web Vitals dans le jeu CrUX de janvier 2022. Les autres manquaient de trafic. C’est courant sur le Web, pas une erreur.

Lorsqu’une URL précise n’a pas de données, les outils appliquent une cascade. Dans PageSpeed Insights : CrUX au niveau URL → si l’échantillon est insuffisant, repli vers CrUX au niveau origine → si l’origine manque aussi, aucune donnée de terrain et seulement la section Lighthouse. Google explique : “The more fine-grained the request is, for example a specific combination of URL and form factor, the fewer user experiences it will include. This may lead to more frequent ‘not found’ errors.” (traduction) « Plus la requête est détaillée, par exemple pour une combinaison précise d’URL et de type d’appareil, moins elle inclut d’expériences ; les erreurs « introuvable » peuvent donc être plus fréquentes. »

Agrégation CrUX : 28 jours et p75

Deux nombres définissent la manière dont CrUX présente les résultats.

La fenêtre glissante de 28 jours. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (traduction) « Les données du Chrome UX Report correspondent à une moyenne glissante sur 28 jours de métriques agrégées. » Chaque résultat porte donc sur les 28 derniers jours. Google souligne que “the collectionPeriod will always show 28-days, even if the data is not for the full 28 days (for example if a page was launched less than 28 days ago).” (traduction) « la période de collecte indiquera toujours 28 jours, même si les données ne couvrent pas réellement les 28 jours complets, par exemple pour une page plus récente. »

Conséquence pratique : les corrections mettent du temps à apparaître. CrUX accuse environ deux jours de retard et agrège une fenêtre passée ; les anciennes sessions doivent sortir de cette fenêtre tandis que de nouvelles expériences admissibles s’accumulent. Compter environ un mois est un ordre de grandeur, pas une garantie. Le délai dépend du trafic admissible, de la durée de vie de la métrique et de la période du relevé. Comme je l’écris dans mon guide CLS, “it takes a while to see the impact of changes.” (traduction) « il faut du temps pour voir l’effet des changements. » Ne promettez donc ni amélioration immédiate ni date exacte.

Le 75e percentile (p75). Les CWV sont évalués au p75, pas à la médiane. Selon Google, “75% of page loads experienced the given metric at or less than this value.” (traduction) « 75 % des chargements de page ont présenté pour cette métrique une valeur inférieure ou égale à celle-ci. » Trois chargements sur quatre doivent donc respecter le seuil « Bon ». Google précise aussi que les percentiles “are synthetically derived, it does not imply that any user actually experienced the value indicated.” (traduction) « sont dérivés synthétiquement ; cela ne signifie pas qu’un utilisateur a réellement connu la valeur indiquée. » Un p75 « Bon » ne signifie pas littéralement que 75 % des utilisateurs sont satisfaits.

Niveau origine ou niveau URL

CrUX publie deux niveaux de granularité, dont la différence est essentielle en SEO.

• Le niveau origine agrège “all data present for all pages in that origin … together” (traduction) « toutes les données disponibles pour toutes les pages de cette origine », soit une moyenne à l’échelle du domaine.
• Le niveau URL renvoie “only data for that specific URL.” (traduction) « uniquement les données de cette URL précise. »

Les deux peuvent fortement diverger. Une origine peut être classée « Bonne » alors qu’une page d’atterrissage importante est « Mauvaise », car les pages rapides compensent les pages lentes dans l’agrégat. Comme PSI se replie vers l’origine lorsqu’une URL manque d’échantillons, vous pouvez croire observer une page alors que vous regardez la moyenne du domaine.

Mon étude a montré cet écart à grande échelle : dans l’échantillon de janvier 2022, environ 33 % des sites validaient les CWV au niveau origine, contre 21,2 % des pages individuelles. Les visites répétées et mises en cache expliquent en partie l’avantage des origines. Ces chiffres sont un instantané historique, pas un taux universel actuel, mais la leçon reste valable : consultez les données URL pour vos pages clés lorsqu’elles existent.

CrUX distingue aussi les types d’appareils : PHONE, TABLET et DESKTOP. Google évalue les données adaptées à chaque type, d’où les différences entre mobile et ordinateur.

Terrain ou laboratoire : pourquoi Lighthouse ne correspond pas

La distinction mérite de la précision. Les données de terrain sont “determined by monitoring all users who visit a page and measuring … each one of those users’ individual experiences” (traduction) « déterminées en observant les utilisateurs qui visitent une page et en mesurant l’expérience individuelle de chacun ». Cette catégorie générale est appelée RUM ; CrUX en est une mise en œuvre publique. Les données de laboratoire sont “determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (traduction) « déterminées en chargeant une page dans un environnement contrôlé avec des conditions réseau et appareil prédéfinies. »

Le terrain “includes a wide variety of network and device conditions as well as a myriad of different types of user behavior,” (traduction) « inclut de très nombreuses conditions réseau et appareil ainsi que des comportements variés », tandis qu’un test de laboratoire “intentionally limits the number of variables” (traduction) « limite volontairement le nombre de variables ». PageSpeed Insights affiche les deux : CrUX en haut pour l’évaluation de Google et Lighthouse en dessous pour le diagnostic. La documentation résume : “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.” (traduction) « CrUX rassemble des expériences réelles de terrain, tandis que Lighthouse est un test contrôlé en laboratoire. »

Si Lighthouse affiche 95 mais que Search Console indique « Amélioration nécessaire », rien n’est cassé : vous comparez un chargement propre et isolé à la réalité plus désordonnée de vos utilisateurs.

CrUX n’est pas équivalent à votre propre RUM. Un outil RUM privé, instrumenté par exemple avec la bibliothèque JavaScript web-vitals, peut produire d’autres chiffres pour la même page, car populations, consentements, échantillonnage et durées de vie des métriques diffèrent. Les trois approches remplissent des rôles distincts :

• CrUX : référence publique et gratuite fondée sur les expériences Chrome admissibles ; utile pour voir ce que Google voit et comparer un concurrent.
• RUM privé : mesure instrumentée de votre audience ; utile pour couvrir tous les navigateurs, segmenter les utilisateurs et déclencher des alertes en temps réel.
• Suivi synthétique (Lighthouse, WebPageTest, etc.) : test contrôlé et reproductible ; utile avant mise en production et pour diagnostiquer pourquoi une métrique de terrain est mauvaise, pas pour déclarer qu’elle est corrigée.

Pour la théorie générale du terrain et du laboratoire, les options RUM, les dispositifs synthétiques et le cadre de décision, consultez le guide Données de terrain ou de laboratoire.

Ce que contient CrUX — et ce qu’il ne contient pas

Les trois Core Web Vitals y figurent : Largest Contentful Paint pour le chargement, Interaction to Next Paint pour la réactivité et Cumulative Layout Shift pour la stabilité visuelle. Ils sont évalués au p75 selon ces seuils :

Outre ces trois métriques, CrUX contient des indicateurs complémentaires comme FCP, le TTFB expérimental et le RTT, qui a remplacé la dimension ECT en janvier 2025, ainsi que les sous-parties d’image LCP et les types de navigation.

CrUX n’inclut pas les diagnostics réservés au laboratoire : Total Blocking Time, Speed Index et Time to Interactive n’y existent pas et viennent de Lighthouse. Autre évolution : INP a remplacé FID comme Core Web Vital en mars 2024 ; FID a quitté CrUX en août 2024, puis BigQuery en septembre. Les guides qui s’appuient encore sur FID sont obsolètes.

Six moyens d’accéder à CrUX

Les cadences, quotas et profondeurs d’historique ci-dessous sont ceux disponibles à la date de rédaction. Google les a déjà modifiés, notamment lors de l’abandon du tableau de bord CrUX. Considérez-les comme un instantané et vérifiez la documentation officielle avant de bâtir un système qui en dépend.

Quelques précisions utiles :

• PageSpeed Insights est le moyen le plus rapide de consulter une URL : terrain en haut, laboratoire en bas ; gratuit, sans clé API.
• Le rapport Core Web Vitals de Search Console regroupe les URL indexées par état, avec des vues mobile et ordinateur. Un groupe peut mélanger des pages rapides et lentes.
• L’API CrUX (POST …/v1/records:queryRecord) renvoie la fenêtre actuelle de 28 jours avec p75 et histogrammes ; interrogez origin ou url. Elle est gratuite avec une clé Google et “limited to 150 queries per minute per Google Cloud project.” (traduction) « limitée à 150 requêtes par minute et par projet Google Cloud. »
• L’API CrUX History fournit jusqu’à 40 semaines d’instantanés hebdomadaires.
• BigQuery offre l’analyse à grande échelle et l’historique depuis 2017, mais uniquement au niveau origine dans les tables standard.
• CrUX Vis (cruxvis.withgoogle.com) est l’outil visuel. L’ancien tableau de bord Looker Studio a été abandonné en novembre 2025 ; utilisez CrUX Vis.

CrUX influence-t-il le classement ?

CrUX alimente le signal d’expérience sur la page, donc un facteur de classement, mais j’en tempère la portée. Dans mon guide Core Web Vitals, j’écris “I don’t expect much, if any, improvement in rankings from improving Core Web Vitals,” (traduction) « Je n’attends guère, voire aucune amélioration du classement après optimisation des Core Web Vitals, » et “unless you are extremely slow, I generally won’t prioritize fixing them.” (traduction) « sauf lenteur extrême, je ne donne généralement pas la priorité à leur correction. » La meilleure raison de suivre CrUX reste l’expérience utilisateur, pas l’espoir d’un bond de classement.

Place de CrUX dans l’écosystème

CrUX est le moteur de données de terrain sous le pilier Core Web Vitals. Chaque métrique possède son guide : Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift. Les deux principaux outils sont PageSpeed Insights, qui réunit terrain et laboratoire, et Google Lighthouse, réservé au laboratoire. Retenez surtout que cette séparation permet à un bon score de laboratoire et à un échec CWV d’être vrais simultanément.

Résumé par IA

Version condensée de l’onglet Avancé :

• CrUX correspond aux données de terrain et alimente les Core Web Vitals. Google consulte CrUX, pas le score Lighthouse, pour évaluer les CWV dans Search.
• La collecte se limite aux expériences Chrome admissibles, selon quatre critères documentés. Elle exclut Chrome sur iOS, WebView, Edge, Safari et Firefox ; elle peut donc sous-représenter une audience très tournée vers Safari.
• La couverture est partielle et l’admissibilité de la page et de l’origine est séparée. Une absence signifie échantillon insuffisant, pas réussite. Dans mon échantillon de janvier 2022, environ 11,9 % des 43,66 millions de pages possédaient une métrique CWV.
• L’agrégation utilise une fenêtre glissante de 28 jours au p75. Une correction met souvent environ un mois à apparaître, sans garantie fixe.
• Origine et URL peuvent diverger. Mon étude observait environ 33 % de réussite au niveau origine contre 21,2 % pour les pages.
• Terrain et laboratoire répondent à des questions différentes. CrUX est une forme publique de RUM ; un RUM privé peut aussi diverger.
• Six interfaces donnent accès aux données : PSI, Search Console, API CrUX, API History, BigQuery et CrUX Vis. Le tableau de bord CrUX a été abandonné en novembre 2025.
• L’effet sur le classement est faible ; l’expérience utilisateur constitue l’enjeu principal.

Documentation officielle

Documentation CrUX de première main publiée par l’équipe Chrome sur developer.chrome.com.

• Présentation de CrUX — définition, rôle dans Web Vitals et usage par Search.
• Méthodologie CrUX — admissibilité, plateformes, règle des 20 %, nettoyage des URL, SPA et iframe.
• API CrUX — fenêtre de 28 jours, p75, queryRecord, quota et mise à jour quotidienne.
• API CrUX History — instantanés hebdomadaires sur 40 semaines.
• CrUX dans BigQuery — publication mensuelle, origine uniquement, historique et pays.
• CrUX Vis — outil visuel remplaçant l’ancien tableau de bord.
• PageSpeed Insights et CrUX — cascade URL, origine, absence et terrain/laboratoire.
• Notes de version CrUX — passage de FID à INP et abandon du tableau de bord.

Contexte complémentaire (web.dev)

• Différences entre données de laboratoire et de terrain — pourquoi Lighthouse et CrUX divergent.
• Différences entre CrUX et RUM — limites Chrome, iOS, SPA et iframe.

Citations de la source

Déclarations officielles tirées de la documentation CrUX de l’équipe Chrome. Chaque lien mène au passage cité.

Définition de CrUX

• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traduction) « Le Chrome User Experience Report, aussi appelé Chrome UX Report ou CrUX, reflète l’expérience de vrais utilisateurs de Chrome sur des destinations populaires du Web. » [Accéder à la citation](https://developer.chrome.com/docs/crux#:~:text=The%20Chrome%20User%20Experience%20Report%20(also%20known%20as%20the%20Chrome%20UX%20Report)
• “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (traduction) « CrUX est le jeu de données Google du programme Web Vitals ; toutes les métriques Core Web Vitals centrées sur l’utilisateur y figurent. » Accéder à la citation

Admissibilité et couverture

• “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” (traduction) « Toutes les origines et pages ne sont pas représentées ; elles doivent notamment être découvrables et recevoir assez de visiteurs pour former un échantillon significatif. » Accéder à la citation
• Les quatre critères utilisateur : “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” (traduction) « Activer les statistiques d’utilisation, synchroniser l’historique, ne pas utiliser de phrase secrète de synchronisation et employer une plateforme prise en charge. » Accéder à la citation

Agrégation

• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (traduction) « Les données du Chrome UX Report sont une moyenne glissante de métriques agrégées sur 28 jours. » Accéder à la citation
• “75% of page loads experienced the given metric at or less than this value.” (traduction) « 75 % des chargements ont connu une valeur inférieure ou égale à celle-ci. » Accéder à la citation
• “The values for each percentile are synthetically derived, it does not imply that any user actually experienced the value indicated, only that some percentage of page loads experienced a metric value that was less than the value given.” (traduction) « Les valeurs de percentile sont dérivées synthétiquement ; elles indiquent seulement qu’une proportion des chargements se situe sous la valeur donnée. » Accéder à la citation

Origine ou URL

• “When the identifier is an origin all data present for all pages in that origin are aggregated together.” (traduction) « Pour une origine, les données de toutes ses pages sont agrégées. » / “When the identifier is a URL, only data for that specific URL will be returned.” (traduction) « Pour une URL, seules les données de cette URL sont renvoyées. » Accéder à la citation

Terrain ou laboratoire (web.dev)

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (traduction) « Les données de terrain proviennent de l’observation des visiteurs et de la mesure de leur expérience individuelle. » Accéder à la citation
• “The Chrome User Experience Report, as its name suggests, is Chrome-only.” (traduction) « Comme son nom l’indique, le Chrome User Experience Report ne couvre que Chrome. » Accéder à la citation

Accès à CrUX — aide-mémoire

Où obtenir les données CrUX et à quoi sert chaque interface — vérifiez la documentation officielle, car les cadences et quotas évoluent.

Repères rapides

• Fenêtre : les 28 derniers jours, même pour une nouvelle page.
• Évaluation : au p75, pas à la moyenne.
• Retard : environ 2 jours ; une correction apparaît souvent en un mois, sans garantie fixe.
• Couverture : expériences Chrome admissibles seulement ; pas Chrome iOS, WebView, Edge, Safari ou Firefox.
• Aucune donnée ? Repli URL → origine → laboratoire. Une absence signifie échantillon insuffisant.
• Terrain ou laboratoire : CrUX observe de vrais utilisateurs ; Lighthouse simule un chargement pour le diagnostic.

Seuils CWV au p75

Outils pour exploiter CrUX

• PageSpeed Insights (pagespeed.web.dev) : vérification rapide par URL, CrUX en haut et Lighthouse en bas.
• Search Console — rapport Core Web Vitals : évaluation du site regroupée par état, séparée entre mobile et ordinateur.
• CrUX Vis (cruxvis.withgoogle.com) : tendances visuelles gratuites sur 40 semaines, au niveau origine ou URL.
• API CrUX (chromeuxreport.googleapis.com/v1/records:queryRecord) : données programmatiques de la fenêtre actuelle.
• API CrUX History (…:queryHistoryRecord) : instantanés hebdomadaires jusqu’à 40 semaines.
• CrUX sur BigQuery (jeu chrome-ux-report) : recherche à grande échelle, origine, pays et historique depuis 2017.
• Chrome DevTools — panneau Performance : données CrUX à côté de la trace locale pour comparer terrain et laboratoire.

Quelle interface CrUX utiliser ?

Erreurs CrUX qui conduisent à de mauvaises décisions

Prendre un repli vers l’origine pour une preuve au niveau page

PageSpeed Insights peut se replier de l’URL vers son origine lorsque l’échantillon est faible. Lisez la portée affichée avant d’affirmer qu’une page réussit ; privilégiez les données URL et étiquetez honnêtement celles de l’origine.

Attendre d’une correction récente qu’elle efface une fenêtre de 28 jours

CrUX est un jeu de données de terrain glissant, pas un test de déploiement en direct. Utilisez le laboratoire ou le RUM pour le diagnostic immédiat, puis laissez les nouvelles expériences remplacer l’ancienne fenêtre.

Présenter Lighthouse comme une mesure CrUX

Lighthouse est un test de laboratoire contrôlé ; CrUX agrège des visites Chrome admissibles. Utilisez Lighthouse pour diagnostiquer une cause, pas pour déclarer corrigée l’évaluation de terrain de Google.

Supposer que CrUX représente tous les utilisateurs

CrUX exclut Safari, Firefox, Edge, Chrome sur iOS, les WebView et les utilisateurs Chrome non admissibles. Comparez-le à un RUM propriétaire si la composition de l’audience rend l’échantillon Chrome peu représentatif.

PageSpeed Insights n’affiche aucune donnée de terrain

Symptôme : la section terrain manque. Cause probable : ni l’URL ni l’origine ne satisfait les exigences CrUX. Correction : vérifiez que la page publique renvoie 200 et reste indexable, puis utilisez le laboratoire ou votre RUM. Contrôlez de nouveau si l’usage réel augmente.

La page est bonne mais l’origine est mauvaise

Symptôme : les résultats URL et origine divergent. Cause probable : l’origine agrège plusieurs types de pages aux performances différentes. Correction : conservez la portée dans le rapport, examinez des URL représentatives des modèles lents et ne mélangez pas les deux relevés.

Lighthouse réussit mais Search Console échoue

Symptôme : le test contrôlé est vert, pas le rapport CWV. Cause probable : les utilisateurs réels ont des appareils, réseaux, caches ou interactions plus lents. Correction : segmentez CrUX par appareil, comparez chaque métrique de terrain au laboratoire et utilisez la trace pour reproduire le goulot.

Une requête API renvoie « introuvable »

Symptôme : aucune fiche ne correspond à une combinaison URL/type d’appareil. Cause probable : l’échantillon admissible est trop petit. Correction : retirez les dimensions facultatives, essayez l’origine et documentez explicitement le repli.

Liste de contrôle pour analyser CrUX

• Indiquer si chaque valeur concerne l’URL ou l’origine.
• Séparer les résultats mobile et ordinateur.
• Confirmer la fenêtre de 28 jours et noter ses dates.
• Lire le p75 comme un percentile de chargements, pas le score d’un utilisateur.
• Vérifier si PSI s’est replié vers l’origine.
• Traiter l’absence comme une couverture insuffisante.
• Comparer séparément LCP, INP et CLS.
• Réserver Lighthouse et DevTools au diagnostic.
• Comparer CrUX au RUM si les utilisateurs non Chrome comptent beaucoup.
• Attendre le renouvellement de la fenêtre avant d’évaluer une correction.

Portée, fenêtre, percentile et population

Chaque résultat CrUX devient plus facile à interpréter lorsque je commence par préciser quatre éléments :

1. Portée : l’URL exacte ou toute l’origine ?
2. Fenêtre : quelle période glissante de 28 jours ?
3. Percentile : le p75, pas une moyenne ni une visite isolée.
4. Population : les utilisateurs Chrome admissibles, pas tout le trafic.

Un rapport qui omet un de ces éléments risque de surestimer la portée du chiffre.

Verdict d’abord, diagnostic ensuite

CrUX répond à la question : qu’ont vécu les utilisateurs réels admissibles ? Une trace de laboratoire explique pourquoi un chargement contrôlé s’est comporté ainsi. Commencez par le verdict de terrain, choisissez la métrique et la portée, puis diagnostiquez en laboratoire. Après correction, validez aussitôt le mécanisme en laboratoire et attendez l’évolution de CrUX pour confirmer l’effet sur la population.

Indicateurs CrUX à suivre

LCP, INP et CLS au p75

Métrique : chaque Core Web Vital au p75. Enseignement : l’expérience de terrain utilisée par Google. Collecte : API CrUX, API History, CrUX Vis ou PSI, en notant portée et appareil. Repère : seuils « Bon » publiés dans cet article, séparément pour les trois métriques. Cadence : tendances hebdomadaires et contrôles quotidiens lors d’un déploiement.

Couverture « Bonne » par modèle de page

Métrique : part des groupes d’URL importants classés « Bons » dans Search Console. Enseignement : étendue des bonnes performances sur le site. Collecte : rapports CWV mobile et ordinateur, associés à l’inventaire des modèles. Repère : établissez une base propre au site et priorisez les modèles précieux et fréquentés. Cadence : hebdomadaire.

Disponibilité des données au niveau URL

Métrique : URL prioritaires possédant leur propre fiche CrUX plutôt qu’un repli vers l’origine. Enseignement : niveau de preuve propre à chaque page. Collecte : consignez le succès des requêtes API et la portée PSI pour un ensemble fixe d’URL. Repère : dépend du trafic Chrome admissible ; ne provoquez pas de trafic artificiel. Cadence : mensuelle.

Testez vos connaissances : Chrome UX Report

Cinq questions rapides sur la portée, la couverture et l’interprétation de CrUX. Choisissez une réponse, puis vérifiez-la.

Ressources utiles

Mes articles connexes

• Étude Core Web Vitals avec CrUX et 5,2 millions de pages — étude associant CrUX à un crawl de 43,66 millions de pages.
• Que sont les Core Web Vitals ? — place de CrUX et effet probable sur le classement.
• Largest Contentful Paint — lecture terrain du LCP.
• Cumulative Layout Shift — pourquoi la fenêtre de 28 jours retarde les progrès visibles.
• Guide PageSpeed Insights — outil qui expose CrUX par URL.

Sources officielles

• Documentation CrUX — référence canonique de l’équipe Chrome.
• Rapport CrUX de HTTP Archive — tableaux publics continus fondés sur CrUX et BigQuery.

Autres sources

• DebugBear — guide Chrome User Experience Report — comparaison technique des outils.
• Lumar — guide SEO sur vitesse, CWV, Lighthouse et CrUX — cadrage SEO.
• SpeedCurve — quand utiliser CrUX, RUM et suivi synthétique — comparaison des trois approches et limites d’iOS.
• GTmetrix — qu’est-ce que CrUX ? — admissibilité et couverture.

Statistiques à citer

• Seules environ 11,9 % des 43,66 millions de pages uniques de Site Audit dans mon échantillon de janvier 2022 possédaient au moins une métrique CrUX. Soit 5,21 millions de pages. Source
• Le taux de réussite au niveau origine dépassait celui des pages : environ 33 % contre 21,2 %. Instantané historique, pas taux universel actuel. Source
• Presque aucun site en 3G ou plus lent ne validait les CWV dans cette étude. “The LCP threshold seems almost impossible to pass on slower connections.” (traduction) « Le seuil LCP semble presque impossible à respecter sur les connexions lentes. » Source
• La géographie influençait les résultats. Les États-Unis occupaient le 38e rang avec environ 41 % de réussite, selon les appareils et réseaux locaux. Source
• Comptez environ un mois pour voir une correction se refléter complètement, avec la fenêtre de 28 jours et le retard d’environ deux jours, sans délai garanti. Source
• Plus de la moitié des origines valident désormais les Core Web Vitals. Lors du jalon d’août 2024, Google indiquait plus de 50 %. Source
• CrUX couvre plus de 15 millions d’origines, selon la documentation méthodologique 2024–2025 de l’équipe Chrome. Source

Journal des modifications