Core Web Vitals : pourquoi Google ignore-t-il les autres métriques de performance pour le Page Experience ?

Google a clarifié une zone d'ombre qui semait la confusion chez beaucoup de praticiens : seuls les trois Core Web Vitals (LCP, FID, CLS) seront utilisés pour évaluer le Page Experience dans l'algorithme de classement. Pas de score Lighthouse global, pas de Time to Interactive, pas de Speed Index.

Cette déclaration met fin aux spéculations sur l'utilisation de métriques complémentaires. L'intention de Google est limpide : se concentrer sur ce qui impacte directement l'expérience utilisateur plutôt que sur des abstractions techniques.

Quelle différence entre données terrain et données lab ?

Les données lab (Lighthouse, PageSpeed Insights en mode lab) simulent un chargement dans des conditions contrôlées — réseau throttlé, device émulé, cache vidé. C'est reproductible, mais complètement déconnecté de la réalité de vos visiteurs réels.

Le Chrome User Experience Report (CrUX), lui, agrège les performances réelles mesurées chez les utilisateurs Chrome dans le monde entier. C'est ce dataset que Google utilise pour calculer vos Core Web Vitals officiels — ceux qui comptent pour le ranking. Si votre trafic réel vient majoritairement de mobiles 4G en zone rurale, vos CWV refléteront cette réalité, pas un test sur fibre optique à Paris.

Pourquoi desktop et mobile sont-ils évalués séparément ?

Parce que les performances sont rarement identiques entre les deux contextes. Un site peut afficher un excellent LCP sur desktop (serveur rapide, connexion stable, device puissant) et se vautrer sur mobile (réseau lent, CPU limité, images non optimisées).

Google indexe et classe séparément mobile et desktop depuis Mobile-First Indexing. Il était logique que les Core Web Vitals suivent cette logique. En pratique, si vous ciblez un trafic majoritairement mobile, c'est votre score mobile CrUX qui compte — et c'est souvent là que ça coince.

Le CrUX Report contient-il toujours des données pour mon site ?

Non, et c'est un point critique. Pour qu'un site apparaisse dans CrUX, il faut un volume minimum de trafic Chrome — Google ne communique pas le seuil exact, mais on estime qu'il faut plusieurs milliers de visiteurs Chrome par mois.

Si votre site est trop petit ou trop récent, vous n'aurez pas de données CrUX origine-level. Google peut alors se rabattre sur des données agrégées au niveau URL, voire ne pas avoir assez de données pour appliquer le signal Page Experience. Dans ce cas, pas de malus… mais pas de bonus non plus.

• Seuls les trois Core Web Vitals (LCP, FID, CLS) comptent pour le Page Experience, pas Lighthouse ni d'autres métriques lab
• Les données CrUX (terrain réel) sont utilisées, pas les simulations en environnement contrôlé
• Desktop et mobile sont évalués indépendamment — optimiser l'un ne garantit rien pour l'autre
• Pas de données CrUX = pas de signal Page Experience appliqué (ni bonus, ni malus)
• Le score Lighthouse reste utile pour diagnostiquer, mais ne prédit pas vos CWV officiels

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et elle tranche enfin un débat qui durait depuis l'annonce initiale du Page Experience. On voyait régulièrement des sites avec des scores Lighthouse catastrophiques mais des CWV CrUX excellents — et inversement. Les premiers ne subissaient aucun impact négatif, les seconds bénéficiaient du boost.

Le cas typique : un site e-commerce bourré de scripts tiers, qui plombe Time to Interactive et Speed Index en lab, mais dont les utilisateurs réels (majoritairement en cache navigateur, connexions rapides) affichent un LCP sous 2,5s et un CLS propre. Google ne pénalise pas ce site, parce que l'expérience réelle est bonne. C'est rationnel.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : Google dit « seuls les Core Web Vitals », mais ça n'empêche pas d'autres signaux indirects de jouer. Un site avec un taux de rebond catastrophique parce qu'il met 8 secondes à charger ne sera pas sauvé par des CWV propres — le comportement utilisateur enverra un signal négatif distinct.

Deuxième nuance : les Core Web Vitals ne sont qu'un tie-breaker léger. John Mueller l'a répété plusieurs fois : le contenu et la pertinence restent prioritaires. Un concurrent avec un contenu médiocre mais des CWV parfaits ne vous dépassera pas si votre contenu est nettement supérieur. Mais à pertinence égale, les CWV font la différence.

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

Si vous n'avez pas assez de trafic Chrome pour figurer dans CrUX, Google ne peut pas appliquer le signal. C'est le cas de nombreux sites B2B de niche, de sites récents, ou de ceux avec un trafic très localisé hors Chrome (Safari dominant dans certains pays).

Autre cas limite : les pages très peu visitées d'un site. CrUX agrège au niveau origine (domaine entier), mais Google peut aussi utiliser des données URL-level quand elles existent. Une page orpheline sans trafic ne générera pas de données CrUX spécifiques — elle héritera du score origine global. [À vérifier] si Google applique une pondération différente selon la granularité des données disponibles.

Que faut-il faire concrètement pour optimiser ses Core Web Vitals ?

Première étape : identifier où vous en êtes réellement avec des données CrUX. La Search Console (section Signaux Web essentiels) vous indique quelles URLs sont « bonnes », « à améliorer » ou « médiocres » selon les seuils officiels. Si vous n'avez pas de données, testez avec l'API CrUX ou attendez d'avoir du trafic.

Ensuite, priorisez les actions par impact. Pour le LCP, regardez le poids et le lazy-loading de votre image hero, la réponse serveur (TTFB), le preload des ressources critiques. Pour le CLS, traquez les images sans dimensions, les pubs qui pushent le contenu, les fontes qui chargent tard. Pour le FID, réduisez le JavaScript lourd en main thread — splittez, différez, élaguez.

Quelles erreurs éviter absolument ?

Ne vous acharnez pas à faire passer Lighthouse de 60 à 95 si vos CWV CrUX sont déjà verts. Vous allez gaspiller du temps sur des optimisations lab qui n'impacteront ni le ranking ni l'expérience réelle. Lighthouse reste un outil de diagnostic, pas une fin en soi.

Autre erreur classique : optimiser uniquement desktop parce que « c'est plus simple ». Si votre trafic est majoritairement mobile (vérifiez Analytics), c'est mobile qu'il faut soigner en priorité. Un LCP desktop à 1,8s et mobile à 4,2s, c'est un échec — Google classe sur mobile d'abord.

Comment vérifier que mon site est conforme aux attentes de Google ?

Le rapport « Signaux Web essentiels » de la Search Console est votre référence absolue. Google y affiche les données CrUX agrégées par groupes d'URLs similaires. Si toutes vos URLs sont en vert (≥75% des visites passent les seuils « bon »), vous êtes OK pour le signal Page Experience.

Complétez avec PageSpeed Insights en mode « données terrain » (onglet CrUX, pas lab). Vous verrez les centiles P75 — c'est ce seuil que Google utilise pour le classement. Un P75 LCP à 2,8s, c'est encore orange, donc marge de progression. Surveillez ces métriques mensuellement, surtout après des déploiements qui touchent le frontend.

• Consulter le rapport Signaux Web essentiels dans Search Console pour connaître votre statut CrUX réel
• Prioriser mobile si c'est votre audience dominante — desktop seul ne suffit plus
• Optimiser LCP (image hero, TTFB, preload), CLS (dimensions, layout stable) et FID (JS léger)
• Ne pas confondre score Lighthouse et Core Web Vitals CrUX — seul le second compte pour le ranking
• Monitorer l'évolution mensuelle via CrUX API ou PageSpeed Insights mode terrain
• Tester les déploiements en staging avec des outils RUM (Real User Monitoring) avant prod