L’analyse des Core Web Vitals à l’échelle d’un portefeuille multi-domaines ou d’un très gros site unique dépasse les capacités des interfaces graphiques standard (PageSpeed Insights, Lighthouse, Search Console). Pour les agences qui gèrent 10+ clients Core Web Vitals ou pour les équipes internes qui opèrent des sites avec des millions de pages, l’accès direct au Chrome User Experience Report (CrUX) via BigQuery devient incontournable. Cette approche data-driven permet des analyses impossibles via les outils graphiques : benchmarks sectoriels, détection de régressions au niveau URL template, corrélations avec d’autres sources de données. Cet article détaille la méthodologie opérationnelle pour exploiter CrUX dans BigQuery.

À retenir en 30 secondes : CrUX dans BigQuery expose les données RUM Core Web Vitals de millions de sites, agrégées mensuellement par origin (domaine). Accessible gratuitement avec un compte Google Cloud et dans la limite du free tier BigQuery (1 TB/mois de requêtes). Permet d’écrire des requêtes SQL pour benchmarks sectoriels, suivis d’évolution par domaine, détection de régressions. L’investissement initial (apprentissage SQL + CrUX schema) est amorti dès qu’on dépasse 10 domaines à monitorer.

Qu’est-ce que CrUX et comment est-il structuré dans BigQuery

Le Chrome User Experience Report (CrUX) est le dataset public des Core Web Vitals collectés par Google via les utilisateurs Chrome ayant opté pour le partage de statistiques de navigation. Il couvre des millions d’origins (domaines racines) et agrège les métriques CWV par mois. Dans BigQuery, le dataset est accessible via chrome-ux-report (projet public), avec des tables par mois (ex: chrome-ux-report.all.202609 pour septembre 2026). Chaque ligne représente une origin + un device (mobile/desktop) avec les distributions complètes de LCP, INP, CLS, TTFB. L’accès nécessite un compte Google Cloud (gratuit) et les requêtes consomment du quota BigQuery (1 TB gratuit par mois, largement suffisant pour la plupart des usages). Pour la vision globale, voir notre guide Core Web Vitals complet.

Requête 1 — Benchmark sectoriel sur une liste de domaines

Première requête utile pour une agence : benchmarker les Core Web Vitals de ses clients vs leurs concurrents. Requête type en SQL : SELECT origin, device, largest_contentful_paint, interaction_to_next_paint, cumulative_layout_shift FROM `chrome-ux-report.all.202609` WHERE origin IN (‘https://client1.com’, ‘https://concurrent1.com’, ‘https://concurrent2.com’). Les résultats permettent de visualiser instantanément la position relative du client. Cette capacité d’analyse structurée est particulièrement précieuse pour justifier des investissements CWV auprès du client : « vos concurrents directs ont un LCP de 1.8s, le vôtre est à 3.2s, vous perdez probablement 15-20% de trafic organique ». Pour l’approche business, voir notre guide pour pitcher une mission SEO technique à un DSI.

Requête 2 — Évolution historique sur 12 mois

Deuxième requête essentielle : suivre l’évolution historique d’un domaine sur 12 mois. Les tables CrUX par mois permettent des UNION pour construire une série temporelle. Requête type : UNION ALL de SELECT ‘YYYY-MM’ AS period, origin, lcp_p75, inp_p75, cls_p75 FROM chrome-ux-report.all.YYYYMM WHERE origin = ‘https://client.com’ pour les 12 derniers mois. Les résultats visualisés en time series révèlent les régressions post-déploiements, l’impact des optimisations, les saisonnalités (certains sites ont des variations CWV liées au trafic saisonnier qui engorge l’infrastructure). Cette capacité de suivi longitudinal est quasi-impossible via les interfaces graphiques classiques limitées aux 28 derniers jours.

Requête 3 — Comparaison par pays ou form factor

CrUX expose également des dimensions pays et form factor (mobile/desktop/tablet). Troisième requête utile : comparer les CWV d’un site entre pays (critique pour les sites internationaux) ou entre devices. Requête type : SELECT country, device, lcp_p75, inp_p75 FROM `chrome-ux-report.country.202609` WHERE origin = ‘https://client.com’ AND country IN (‘fr’, ‘de’, ‘it’, ‘es’, ‘us’). Les résultats révèlent les disparités : un site français hébergé sans CDN mondial aura typiquement des CWV significativement dégradés pour les utilisateurs allemands ou américains. Ces disparités orientent les décisions d’infrastructure (CDN, hébergement régional). Pour la méthodologie infrastructure, voir notre guide sur l’influence d’un CDN sur les Core Web Vitals.

Automatiser les analyses via Looker Studio connecté à BigQuery

L’exécution manuelle de requêtes BigQuery n’est pas scalable sur un portefeuille client important. L’automatisation via Looker Studio connecté à BigQuery permet de construire des dashboards actualisés mensuellement sans intervention humaine. Workflow type : (1) écrire les requêtes SQL une fois, les sauvegarder en vues BigQuery. (2) Connecter Looker Studio à ces vues. (3) Construire des visualisations réutilisables (évolutions, benchmarks, cartes par pays). (4) Partager les dashboards aux clients via lien ou intégration. L’investissement initial (3-5 jours agence pour setup) est amorti sur l’ensemble du portefeuille client. Pour la méthodologie reporting, voir notre guide des 7 livrables SEO pour un rapport trimestriel.

Limites et pièges méthodologiques

CrUX a plusieurs limites méthodologiques à connaître. Premièrement, les sites à faible trafic Chrome ne sont pas inclus dans le dataset (seuil estimé autour de 5000 pages vues mensuelles par origin). Beaucoup de sites de niche B2B français sont absents de CrUX. Deuxièmement, la granularité par origin (domaine racine) ne permet pas de distinguer les performances par URL template : impossible de voir si c’est la home ou les fiches produit qui dégradent le LCP. Pour cette granularité fine, il faut passer par du RUM dédié (SpeedCurve, DebugBear, web-vitals.js intégré). Troisièmement, le décalage temporel : les données CrUX sont publiées mensuellement avec 1 mois de retard. Pour un monitoring quasi-temps-réel, le RUM dédié reste nécessaire. Pour l’ensemble des outils, voir notre guide SEO technique pour agences et consultants.

Pour la documentation officielle sur CrUX dans BigQuery, la page Chrome Developers dédiée et le méthodologie CrUX restent les références incontournables pour comprendre les données et leurs limites.

Mon point de vue d’expert

En consulting Core Web Vitals auprès d’agences et grands comptes, l’exploitation de CrUX dans BigQuery est la discipline qui distingue les équipes CWV matures des équipes qui restent sur Lighthouse. Les benchmarks sectoriels, les suivis longitudinaux, les analyses multi-pays deviennent accessibles et transforment la conversation client : au lieu de « optimisons votre LCP », on peut dire « votre LCP est à 2.8s, vos 5 concurrents directs sont à 1.5-2.0s, vous perdez probablement X% de trafic organique à cause de ce gap ». Mon conseil pour les responsables SEO technique : investissez 3-5 jours pour vous former à SQL + CrUX schema + Looker Studio, construisez vos premières requêtes benchmark, intégrez-les à votre dashboard client. L’investissement initial est modeste, mais vous passerez dans une classe différente de maturité CWV, et vos propositions commerciales et vos reportings gagneront en autorité technique mesurable.

FAQ — CrUX et BigQuery pour les Core Web Vitals

Combien coûte l’accès à CrUX dans BigQuery ?
CrUX est un dataset public gratuit dans BigQuery. Les coûts éventuels viennent uniquement de l’exécution des requêtes qui consomment du quota BigQuery (0,02€ par Go de données scannées au-delà du free tier de 1 To/mois). Pour une agence qui scanne quelques domaines par semaine, le coût effectif est généralement de 0€/mois dans le free tier. Les gros usages (automatisation massive de requêtes) peuvent générer quelques dizaines à centaines d’euros par mois.
Tous les sites sont-ils dans CrUX ?
Non, seulement les sites qui ont assez de trafic Chrome pour atteindre le seuil de confidentialité imposé par Google (estimé autour de 5000 pages vues mensuelles par origin). Beaucoup de sites de niche, de petites entreprises B2B, de nouveaux sites ne sont pas inclus. Pour ces sites, le RUM dédié (SpeedCurve, DebugBear, web-vitals.js) reste nécessaire.
CrUX dans BigQuery ou dans l’API CrUX ?
Les deux ont leurs usages. L’API CrUX (gratuit, requêtes simples) convient aux usages ponctuels : vérifier rapidement les CWV d’un site, requêtes isolées. BigQuery convient aux usages structurés et scalables : benchmarks sur de nombreux domaines, suivis longitudinaux, intégration à des dashboards. Pour une agence sérieuse, BigQuery devient le choix dominant dès qu’on dépasse quelques domaines à monitorer régulièrement.
Peut-on avoir les CWV par URL dans CrUX ?
Dans le dataset BigQuery historique (chrome-ux-report), non : la granularité est par origin (domaine racine). Depuis 2022, Google a introduit un dataset expérimental (chrome-ux-report.experimental) qui expose certains sites à granularité URL. La couverture reste limitée mais s’étend progressivement. Pour une granularité URL fiable sur tous les sites, le RUM dédié reste la meilleure solution.
Article similaire