Les tests PageSpeed mentent-ils sur vos Core Web Vitals ?

Pourquoi Google préfère-t-il les données terrain aux tests en laboratoire ?

Les tests en laboratoire (Lighthouse, WebPageTest, PageSpeed Insights en mode labo) tournent dans des conditions contrôlées : appareil simulé, connexion stable, pas de cache, pas d'extensions navigateur. Ces tests sont reproductibles et pratiques pour débugger, mais ils ne reflètent jamais la diversité des configurations réelles.

Le Chrome User Experience Report agrège les métriques de millions d'utilisateurs Chrome qui ont accepté de partager leurs données de navigation. Google collecte les Core Web Vitals (LCP, INP, CLS) tels qu'ils se produisent dans des conditions réelles : 4G instable, CPU sous-performant, extensions actives, cache plein ou vide. Cette donnée terrain capture la variabilité du monde réel.

La distinction est capitale. Un site peut scorer 95/100 en labo sur une connexion fibre et un MacBook Pro, puis planter à 2,8 secondes de LCP sur un Samsung Galaxy A avec un réseau 3G fluctuant. Google indexe et classe en fonction de ce que les utilisateurs vivent vraiment, pas de ce qu'un bot mesure dans un environnement idéal.

Comment CrUX collecte-t-il ces données réelles ?

CrUX repose sur le consentement explicite des utilisateurs Chrome qui activent l'option « Améliorer Chrome en envoyant des statistiques d'utilisation et des rapports d'erreur ». Seuls ces utilisateurs contribuent aux données. Google agrège ensuite les métriques par origine (domaine entier) et par URL (pages individuelles si suffisamment de trafic).

Les données sont publiées avec un décalage de 28 jours glissants : ce que vous voyez aujourd'hui dans le rapport CrUX correspond aux quatre dernières semaines. Cela signifie qu'une amélioration déployée hier ne sera pleinement reflétée dans CrUX que dans un mois environ. Les tests labo, eux, capturent instantanément les changements — mais ne garantissent rien sur l'impact réel.

Google filtre les données pour garantir un minimum de volume et d'anonymat. Si votre page n'a pas assez de visiteurs Chrome avec le partage activé, elle n'apparaîtra pas dans CrUX. Dans ce cas, Google se rabat sur les données de l'origine entière. Pas d'origine dans CrUX ? Alors vos Core Web Vitals ne sont pas évalués dans le classement — mais ce cas est rare pour des sites avec trafic significatif.

Quelle différence entre « origine » et « URL » dans CrUX ?

CrUX distingue deux niveaux de granularité. L'origine agrège toutes les pages d'un domaine (ex: https://example.com). L'URL représente une page spécifique (ex: https://example.com/blog/article-123). Google privilégie les données URL quand elles existent, mais se rabat sur l'origine si le volume est insuffisant.

Concrètement : un site avec une homepage rapide mais des fiches produit lentes verra des données moyennes au niveau origine, qui peuvent masquer des problèmes localisés. Inversement, une page très consultée avec de mauvaises métriques peut tirer l'origine vers le bas. Surveiller les deux niveaux est indispensable pour identifier où agir.

• CrUX reflète l'expérience réelle de millions d'utilisateurs Chrome, pas un environnement simulé.
• Les données sont publiées avec 28 jours de latence — les corrections prennent du temps à se refléter.
• Google classe sur CrUX, pas sur Lighthouse — un score labo parfait ne garantit rien côté ranking.
• Origine vs URL : Google utilise les données URL si disponibles, sinon l'origine entière.
• Pas dans CrUX ? Vos Core Web Vitals ne pèsent pas dans le classement, mais ce cas reste marginal.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est vérifiable. Depuis le déploiement du Page Experience Update, les corrélations entre classement et données CrUX sont documentées, tandis que les scores Lighthouse seuls ne prédisent rien. J'ai vu des sites scorer 98/100 en labo stagner en position 8-12, et des concurrents à 72/100 mais avec CrUX au vert grimper en top 3. Le terrain confirme : Google ne ment pas sur ce point.

La nuance — et elle est énorme — c'est que CrUX ne couvre que les utilisateurs Chrome avec partage activé. Cela représente une fraction du trafic réel, biaisée vers certaines zones géographiques et certains types d'utilisateurs. Mais Google assume ce biais : il ne prétend pas mesurer tous les utilisateurs, juste un échantillon suffisamment large pour être représentatif. En pratique, CrUX capte assez de diversité pour refléter les tendances réelles.

Un point rarement souligné : les données CrUX incluent les visiteurs avec cache navigateur activé, extensions bloquant des scripts, connexions dégradées. C'est ce qui les rend précieuses — et c'est aussi pourquoi un site peut bien performer en labo (cache vide, pas d'extensions) mais mal en production. Les tests labo restent utiles pour débugger, mais ils ne doivent jamais servir de proxy pour le classement.

Quelles limites faut-il connaître avant de prendre CrUX pour argent comptant ?

CrUX agrège sur 28 jours glissants. Cela lisse les pics et les creux, mais ça signifie aussi qu'une optimisation déployée aujourd'hui mettra un mois à être pleinement reflétée. Si vous corrigez un LCP catastrophique lundi, ne vous attendez pas à voir votre classement bouger mardi — Google continue de voir les quatre semaines précédentes. Cette latence déroute beaucoup de praticiens qui s'attendent à une réactivité immédiate.

Autre limite : CrUX ne publie pas de données pour toutes les URLs individuelles. Si une page n'a pas assez de trafic Chrome, elle n'apparaît pas. Google se rabat alors sur les données de l'origine, ce qui peut masquer des problèmes localisés. Une fiche produit ultra-lente avec peu de visiteurs ne fera pas bouger les métriques globales — mais elle peut quand même nuire à l'expérience et aux conversions. [À vérifier] : Google n'a jamais publié le seuil de volume nécessaire pour qu'une URL apparaisse dans CrUX.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre site n'est pas dans CrUX — typiquement un site très faible trafic, ou un intranet, ou un domaine neuf — alors Google ne peut pas évaluer vos Core Web Vitals. Vous ne serez ni récompensé ni pénalisé sur ce critère. Le classement repose alors uniquement sur les autres signaux (pertinence, backlinks, contenu, etc.). Ce n'est pas un drame, mais vous perdez un levier d'optimisation.

Autre cas : les sites avec trafic fortement biaisé géographiquement. CrUX agrège globalement par défaut, mais PageSpeed Insights permet de filtrer par pays. Si 95 % de votre trafic vient de France et que vos serveurs sont optimisés pour l'Europe, vos données CrUX globales peuvent être tirées vers le bas par quelques visiteurs lointains avec latence élevée. Analysez les données segmentées par région pour mieux comprendre où agir.

Enfin, les pages derrière authentification ou paywalls ne génèrent pas de données CrUX publiques. Google peut collecter ces métriques en interne (si les utilisateurs sont loggés Chrome), mais elles ne sont pas exposées dans les APIs publiques. Vous devrez vous appuyer sur vos propres outils RUM pour monitorer l'expérience réelle sur ces pages.

Que faut-il faire concrètement pour optimiser sur CrUX plutôt que sur les tests labo ?

Commencez par monitorer CrUX en continu, pas juste Lighthouse. Utilisez PageSpeed Insights pour consulter les données terrain de vos URLs et de votre origine. Complétez avec l'API CrUX (gratuite) ou BigQuery (dataset public) pour suivre l'évolution hebdomadaire. Si vos données labo sont au vert mais CrUX dans le rouge, c'est CrUX qui dicte votre classement — concentrez-vous là-dessus.

Identifiez les écarts entre labo et terrain. Si Lighthouse affiche 1,2 s de LCP mais CrUX 3,8 s, cherchez les causes côté utilisateurs réels : cache CDN mal configuré, ressources bloquantes sur certains pays, scripts tiers qui explosent le temps de chargement sur mobile. Activez un outil RUM (Real User Monitoring) pour capturer les métriques de 100 % de vos visiteurs, pas juste l'échantillon Chrome. Cela vous donnera une vision plus fine que CrUX seul.

Optimisez en priorité les pages à fort trafic qui tirent vos métriques d'origine vers le bas. Une homepage visitée 10 000 fois par jour pèse plus lourd dans CrUX qu'une landing page de campagne à 50 visites. Corrigez d'abord ce qui impacte le plus de monde. Utilisez Search Console pour croiser les URLs avec mauvaises métriques et celles qui génèrent le plus de trafic organique.

Quelles erreurs éviter absolument ?

Ne vous fiez jamais uniquement aux scores Lighthouse pour valider vos optimisations. Un site peut passer de 68 à 94 en labo après avoir différé quelques scripts, mais si ces scripts se chargent quand même côté utilisateur et dégradent l'expérience réelle, CrUX ne bougera pas — et votre classement non plus. Validez toujours sur CrUX avant de déclarer victoire.

Autre piège : déployer une optimisation et checker CrUX le lendemain. Vous verrez encore les 28 jours précédents. Attendez au moins trois à quatre semaines pour mesurer l'impact réel. Pendant ce temps, surveillez vos outils RUM en temps réel pour confirmer que l'amélioration se produit bien côté utilisateurs. Cette patience est difficile à vendre en interne, mais elle évite des conclusions hâtives.

Enfin, ne négligez pas les données segmentées par appareil (mobile vs desktop) et par région. CrUX publie des métriques séparées pour chaque dimension. Un site peut être au vert sur desktop et catastrophique sur mobile. Google indexe et classe majoritairement sur la version mobile — si vos Core Web Vitals mobile sont dans le rouge, vous perdez du terrain même si desktop est parfait.

Comment vérifier que mon site est bien suivi dans CrUX ?

Rendez-vous sur PageSpeed Insights, entrez votre URL, et scrollez jusqu'à la section « Découvrir les performances réelles de cette page ». Si vous voyez des données CrUX (LCP, INP, CLS avec répartition Bon/À améliorer/Médiocre), votre page est trackée. Si le message indique « Les données de terrain ne sont pas disponibles pour cette URL », Google se rabat sur les données de l'origine. Pas de données d'origine non plus ? Votre site n'est pas dans CrUX.

Autre méthode : interrogez l'API CrUX directement (gratuite, pas de clé requise pour les requêtes publiques). Vous pouvez vérifier à la fois les données URL et origine, filtrer par appareil (mobile/desktop/tablette) et par région. C'est plus flexible que PageSpeed Insights et permet d'automatiser le suivi. Si vous gérez des centaines de pages, c'est la seule approche scalable.

Mettez en place des alertes automatiques si vos métriques CrUX dégradent. Un changement de thème, un nouveau plugin, un CDN mal configuré peuvent faire basculer vos Core Web Vitals du vert au rouge en quelques jours — mais vous ne le verrez dans CrUX qu'un mois plus tard. Un outil RUM en temps réel vous alerte immédiatement, avant que Google n'enregistre la dégradation. Cela laisse une fenêtre pour corriger avant impact sur le classement.

• Monitorer CrUX hebdomadairement via PageSpeed Insights ou l'API CrUX, pas uniquement Lighthouse.
• Activer un outil RUM (Real User Monitoring) pour capturer 100 % des visiteurs, tous navigateurs confondus.
• Prioriser les optimisations sur les pages à fort trafic qui dégradent les métriques d'origine.
• Attendre 3-4 semaines après déploiement pour mesurer l'impact réel dans CrUX.
• Segmenter les données par appareil (mobile prioritaire) et par région pour identifier les zones de faiblesse.
• Ne jamais valider une optimisation uniquement sur les scores labo — vérifier CrUX systématiquement.