Les Core Web Vitals sont-ils vraiment mesurés depuis les bots Google ou depuis vos utilisateurs réels ?

D'où viennent exactement les données des Core Web Vitals ?

Les Core Web Vitals s'appuient sur le Chrome UX Report (CrUX), une base de données publique qui agrège les métriques de performance réelles collectées auprès des utilisateurs de Chrome ayant activé la synchronisation et l'envoi de statistiques d'utilisation. Pas de bot Googlebot dans l'équation : on parle de vrais navigateurs, de vraies connexions, de vrais appareils.

Concrètement, chaque fois qu'un utilisateur Chrome charge votre page, son navigateur mesure le LCP (Largest Contentful Paint), le FID (First Input Delay) ou le INP (Interaction to Next Paint) qui l'a remplacé, ainsi que le CLS (Cumulative Layout Shift). Ces données sont anonymisées, agrégées par origine (domaine), puis mises à disposition via CrUX avec un décalage d'environ 28 jours.

C'est ce jeu de données agrégé que Google utilise pour évaluer l'expérience utilisateur réelle de votre site dans le cadre du Page Experience signal de ranking. Les bots, eux, ne mesurent rien de tout ça — ils crawlent, rendent le HTML/JS si nécessaire, indexent, mais ne génèrent aucune métrique CWV exploitable pour le classement.

• Les Core Web Vitals sont des métriques field, pas lab : elles reflètent l'expérience réelle des utilisateurs, pas un environnement contrôlé.
• Le CrUX collecte des données uniquement depuis Chrome desktop et mobile, avec un panel mondial représentatif mais limité aux utilisateurs ayant accepté le partage de statistiques.
• Les bots Google (Googlebot, Googlebot Smartphone) ne contribuent jamais au CrUX : leurs requêtes sont exclues de toute mesure CWV.
• Le décalage de publication CrUX (28 jours) signifie que vos optimisations techniques ne se refléteront dans les scores qu'un mois plus tard.
• Les données CrUX sont publiques et accessibles via BigQuery, l'API CrUX, PageSpeed Insights ou la Search Console.

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même l'un des rares points sur lesquels Google a toujours été clair et constant. Depuis le lancement des Core Web Vitals en 2020, tous les signaux concordent : CrUX = field data uniquement. Les tests terrain confirment qu'un site crawlé par Googlebot mais sans trafic Chrome réel n'aura jamais de données CWV dans la Search Console. Inversement, un site avec du trafic Chrome mais bloqué au crawl peut très bien apparaître dans CrUX.

Cette cohérence est rassurante, mais elle masque un angle mort : Google ne précise jamais le seuil de trafic minimum requis pour qu'un site apparaisse dans CrUX. Les sites à faible volume de visiteurs Chrome — typiquement les sites B2B de niche, les intranets partiellement ouverts, ou les sites très Firefox/Safari — peuvent tout simplement n'avoir aucune donnée CWV exploitable. Dans ce cas, Google se rabat sur des données d'origine (domaine entier) ou, si rien n'est disponible, ignore probablement le signal CWV pour ces URLs.

Le dynamic rendering fausse-t-il vraiment les Core Web Vitals ?

Non, il ne les fausse pas — il les dissocie de ce que voient les bots, ce qui est différent. Si vous servez une version server-side rendered (SSR) ou prérendue statique à Googlebot via dynamic rendering, mais que vos utilisateurs réels reçoivent une SPA lourde en JavaScript avec hydratation côté client, ce sont les performances de la version JS qui compteront pour vos CWV. Googlebot n'a aucune influence sur ces scores.

En pratique, ça peut créer un écart gênant : votre version bot est rapide, bien indexée, mais vos utilisateurs réels souffrent de LCP pourris et de CLS chaotiques. Résultat ? Indexation nickel, mais ranking pénalisé par de mauvais CWV. L'inverse est plus rare mais possible : une version bot lente (par exemple avec du JS bloquant non optimisé) mais une version client fluide grâce à du lazy-loading agressif — dans ce cas, vos CWV seront bons même si le rendering côté bot est laborieux. [A vérifier] : Google n'a jamais publié de données croisant dynamic rendering et impact CWV à grande échelle, donc tout ceci reste du retour d'expérience terrain.

Quelles sont les limites de cette approche field-only ?

Le principal problème, c'est que CrUX n'est pas exhaustif. Seuls les utilisateurs Chrome contribuent, ce qui exclut Safari (majoritaire sur iOS), Firefox, Edge non-Chromium, et tous les navigateurs de niche. Si votre audience est à 60% Safari, vos CWV ne reflètent que les 40% Chrome — potentiellement un biais si les deux populations ont des comportements différents (ex: mobile vs desktop, 4G vs fibre).

Autre limite : le délai de 28 jours rend toute optimisation réactive difficile. Vous corrigez un bug CLS critique aujourd'hui, vous ne verrez l'effet dans Search Console que dans un mois. Entre-temps, votre ranking peut avoir souffert. Enfin, les sites à très faible trafic Chrome n'ont tout simplement pas de données CWV URL-level, ce qui les prive d'un levier de différenciation face à des concurrents mieux dotés en volume.

Faut-il abandonner le dynamic rendering si on veut de bons Core Web Vitals ?

Pas nécessairement. Le dynamic rendering reste une solution pragmatique pour des architectures SPA complexes où la migration vers du SSR ou de l'Isomorphic Rendering représenterait des mois de dev. Mais si vous l'utilisez, assumez que vos CWV refléteront la version client, donc optimisez impérativement cette version : code-splitting, lazy-loading des images, réduction du JavaScript bloquant, preload des ressources critiques, utilisation de Service Workers pour le cache.

L'erreur classique consiste à soigner uniquement la version servie aux bots en pensant que ça suffira pour le ranking. Faux. Les bots ne votent pas pour vos CWV. Ce sont vos utilisateurs Chrome, sur mobile 3G en banlieue parisienne ou sur desktop fibre optique à Bordeaux, qui déterminent si votre LCP est sous les 2,5 secondes ou au-delà.

Comment vérifier que mes Core Web Vitals sont bien mesurés côté utilisateur réel ?

Consultez la Search Console (section Signaux web essentiels) : si des données apparaissent, c'est que vous avez suffisamment de trafic Chrome pour alimenter CrUX. Vous pouvez aussi interroger l'API CrUX ou PageSpeed Insights en mode field data. Si aucune donnée n'apparaît, soit votre trafic Chrome est trop faible, soit votre site est trop récent (CrUX nécessite un historique de 28 jours minimum).

Pour monitorer en continu, déployez le web-vitals.js de Google (bibliothèque JavaScript open-source) qui envoie les métriques réelles vers votre système d'analytics (Google Analytics 4, Matomo, ou un endpoint custom). Ça vous permet de croiser vos propres données field avec CrUX et de détecter des régressions en temps réel, sans attendre la publication CrUX mensuelle.

Quelles actions concrètes pour aligner bot et utilisateurs sur les performances ?

L'idéal reste de servir la même version aux bots et aux utilisateurs, ce qui élimine toute divergence. Si vous êtes en dynamic rendering, migrez progressivement vers du SSR (Next.js, Nuxt, SvelteKit) ou du Static Site Generation (SSG) avec hydratation partielle. Si la migration full-stack est hors budget, priorisez au moins les pages stratégiques (home, catégories, fiches produits top).

En attendant, optimisez la version client comme si votre ranking en dépendait — parce que c'est le cas. Utilisez un CDN pour réduire la latence, compressez vos assets (WebP, AVIF pour les images ; Brotli pour le texte), différez le chargement des scripts non-critiques, et éliminez les layout shifts en réservant l'espace des images/ads dès le rendu initial.

• Vérifiez la présence de données CrUX pour votre domaine dans PageSpeed Insights ou Search Console.
• Déployez web-vitals.js pour monitorer les CWV en temps réel côté utilisateur et détecter les régressions avant publication CrUX.
• Si vous utilisez du dynamic rendering, auditez la version client (celle que reçoivent les utilisateurs) avec Lighthouse et WebPageTest, pas seulement la version bot.
• Priorisez le mobile : CrUX mobile pèse davantage dans le ranking, et c'est souvent là que les scores sont les plus dégradés (réseaux lents, CPU faibles).
• Planifiez une migration progressive vers SSR ou SSG si votre architecture SPA actuelle génère des CWV médiocres malgré les optimisations.
• Documentez l'écart entre lab data (Lighthouse) et field data (CrUX) pour expliquer aux parties prenantes pourquoi un bon score Lighthouse ne garantit pas un bon ranking.