Les Core Web Vitals sont-ils réellement mesurés sur les utilisateurs ou sur les bots ?

D'où proviennent réellement les données des Core Web Vitals ?

Les Core Web Vitals ne sont pas calculés lors du crawl de Googlebot. Ils s'appuient sur le Chrome UX Report (CrUX), un dataset public qui agrège des métriques de performance collectées auprès d'utilisateurs réels naviguant avec Chrome.

Cela signifie que Google mesure le LCP, FID (devenu INP) et CLS directement dans le navigateur des visiteurs de votre site. Pas de simulation, pas de headless Chrome côté serveur : ce sont des données terrain, anonymisées et agrégées sur 28 jours glissants.

Pourquoi le dynamic rendering ne change rien aux CWV ?

Le dynamic rendering consiste à servir une version HTML pré-rendue aux bots, et une version JavaScript classique aux utilisateurs. Cette technique permet d'améliorer l'indexation du contenu JavaScript sans pénaliser l'expérience utilisateur.

Mais comme les CWV sont mesurés côté client, chez les vrais visiteurs, le contenu servi à Googlebot n'a aucun impact. Si votre site sert du JavaScript lourd aux utilisateurs, vos scores CWV seront mauvais même si le bot reçoit du HTML statique ultra-rapide.

Quelle est la différence entre rendu bot et expérience utilisateur ?

Googlebot peut crawler et indexer un site avec un rendu JavaScript côté serveur optimisé, ce qui facilite la découverte du contenu. Mais cette version optimisée n'est jamais celle que voit l'utilisateur final.

L'utilisateur, lui, télécharge le HTML, exécute le JavaScript, déclenche les requêtes réseau, attend le rendu des composants. C'est cette expérience-là que Chrome mesure et remonte dans CrUX. Google ne triche pas : il mesure ce que vit réellement votre audience.

• Les Core Web Vitals proviennent du Chrome UX Report (données utilisateurs réels sur 28 jours)
• Le dynamic rendering ne modifie pas les métriques CWV, car elles sont mesurées côté client
• Optimiser le rendu pour Googlebot améliore l'indexation, pas la performance perçue par les visiteurs
• Pour améliorer les CWV, il faut travailler l'expérience utilisateur réelle, pas la version servie aux bots
• Les données CrUX sont publiques et consultables via PageSpeed Insights ou la Search Console

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

Oui, et c'est même rassurant. Sur des milliers d'audits, on constate que les sites qui trichent en servant du contenu ultra-optimisé aux bots mais du JavaScript obèse aux utilisateurs n'ont aucun avantage sur les CWV. Les scores PageSpeed Insights reflètent bien l'expérience réelle, pas une version fantasmée côté serveur.

En revanche, certains clients croient encore qu'optimiser le rendu pour Googlebot va magiquement améliorer leurs scores. C'est une confusion fréquente entre crawlabilité (ce que le bot voit) et performance utilisateur (ce que mesure CrUX). Cette déclaration de Splitt coupe court à cette idée reçue.

Quelles nuances faut-il apporter à cette affirmation ?

Le CrUX ne couvre pas tous les sites. Pour apparaître dans le rapport, il faut un volume de trafic Chrome suffisant sur 28 jours. Les sites à faible audience n'ont pas de données terrain, et Google utilise alors des estimations ou des données agrégées par origine (domaine entier plutôt que page par page). [A vérifier] : le seuil exact de trafic requis n'est pas public, mais on estime qu'il faut plusieurs milliers de sessions mensuelles.

Autre point : les utilisateurs Chrome ne représentent qu'une part de votre audience totale. Si 40 % de vos visiteurs sont sur Safari ou Firefox, leurs métriques ne remontent pas dans CrUX. Cela peut créer un biais, notamment sur mobile où Safari domine sur iOS. Mais Google n'a accès qu'aux données Chrome, donc c'est ce dataset qu'il utilise pour le ranking.

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

Si votre site n'a aucune donnée CrUX (trafic trop faible, site neuf), Google ne peut pas utiliser les Core Web Vitals comme signal de ranking. Dans ce cas, les CWV ne pèsent tout simplement pas dans l'algorithme — ni positivement, ni négativement.

Par ailleurs, attention aux tests Lighthouse en lab (PageSpeed Insights en mode simulé). Ces tests ne reflètent pas forcément CrUX : ils tournent dans un environnement contrôlé, sans cache, avec une connexion calibrée. Ils donnent des pistes d'optimisation, mais seules les données terrain (CrUX) comptent pour le ranking.

Que faut-il faire concrètement pour optimiser les CWV ?

Première étape : mesurer les données réelles. Consultez la Search Console (section Signaux Web essentiels) et PageSpeed Insights avec l'onglet CrUX activé. Ces données terrain montrent ce que vivent vos utilisateurs, pas ce que simule un test en lab.

Ensuite, concentrez-vous sur l'expérience utilisateur réelle : réduisez le poids des JavaScript, optimisez le rendu critique, éliminez les layout shifts. Le dynamic rendering peut aider à l'indexation, mais il ne remplacera jamais une vraie optimisation côté client. Si vous servez du contenu lourd aux visiteurs, vos CWV seront mauvais, point final.

Quelles erreurs éviter dans l'optimisation des Core Web Vitals ?

Ne perdez pas de temps à optimiser la version bot si votre objectif est d'améliorer les CWV. Servir du HTML statique ultra-rapide à Googlebot tout en envoyant du JavaScript obèse aux utilisateurs ne vous aidera en rien. Google mesure ce que voit l'utilisateur final, pas ce que crawle le bot.

Autre erreur classique : se fier uniquement aux tests Lighthouse. Ces tests donnent des recommandations utiles, mais seules les données CrUX comptent pour le ranking. Un score Lighthouse parfait avec un CrUX catastrophique signifie que vos utilisateurs réels souffrent — et c'est ça que Google pénalise.

Comment vérifier que mon site respecte bien cette logique ?

Comparez vos données CrUX (Search Console, PageSpeed Insights) avec vos analytics réels. Si vous voyez un écart énorme entre les tests en lab et les données terrain, c'est souvent le signe de ressources tierces (publicités, tracking) qui pèsent lourd en production mais sont absentes en environnement de test.

Testez également sur des connexions réelles : 4G moyen de gamme, WiFi saturé, anciens terminaux. Les tests en lab simulent rarement ces conditions, mais ce sont elles que vivent vos utilisateurs — et que mesure CrUX. Si votre site est fluide en lab mais laggy en conditions réelles, vos scores CWV le refléteront.

• Consulter les données CrUX dans la Search Console et PageSpeed Insights (données terrain sur 28 jours)
• Optimiser l'expérience utilisateur réelle : JavaScript, rendu critique, layout shifts
• Ne pas confondre dynamic rendering (indexation) et optimisation CWV (performance client)
• Comparer les tests Lighthouse (lab) avec les métriques CrUX (terrain) pour identifier les écarts
• Tester sur connexions réelles (4G, anciens terminaux) pour valider l'expérience utilisateur
• Surveiller les ressources tierces (ads, tracking) qui peuvent dégrader les CWV en production