Les Core Web Vitals mesurent-ils vraiment ce que vos utilisateurs voient ?

Quelle version de page Google prend-il en compte pour les Core Web Vitals ?

Google mesure les Core Web Vitals sur la version qui s'affiche réellement dans le navigateur de l'utilisateur. Si votre site propose une version AMP et que c'est celle qui se charge depuis les résultats de recherche, c'est cette version AMP qui sera évaluée. Si l'utilisateur atterrit sur la version HTML classique, c'est elle qui compte.

Cette logique suit le principe d'expérience utilisateur réelle : Google ne mesure pas une version théorique ou technique, mais ce que les gens voient concrètement. Les données remontées via le Chrome User Experience Report (CrUX) reflètent cette réalité terrain, pas un environnement de test contrôlé.

Pourquoi cette distinction est-elle importante pour les sites AMP ?

De nombreux sites ont déployé AMP pour bénéficier d'un affichage prioritaire dans les carrousels mobiles ou améliorer leur vitesse perçue. Mais si l'essentiel du trafic organique atterrit sur AMP, alors les optimisations de performance sur la version HTML classique deviennent secondaires pour le classement lié aux Core Web Vitals.

À l'inverse, si votre stratégie consiste à abandonner AMP et à tout miser sur une version HTML ultra-optimisée, il faut s'assurer que c'est bien cette version que les utilisateurs chargent. Sinon, vous optimisez la mauvaise cible. La cohérence entre configuration technique et trafic réel devient critique.

Comment Google collecte-t-il ces données de performance réelle ?

Les Core Web Vitals sont mesurés via le CrUX, qui agrège les données de navigation anonymes des utilisateurs Chrome. Chaque visite génère des métriques (LCP, FID, CLS) qui sont associées à l'URL effectivement chargée. Si un utilisateur arrive sur exemple.com/amp/article, c'est cette URL qui sera évaluée.

Cette approche terrain signifie que les variations de performance selon les appareils, connexions et géographies sont prises en compte. Un site peut performer différemment sur mobile 4G en Inde et sur desktop fibre en France — Google mesure ces deux réalités, pas un score synthétique unique.

• Version AMP : mesurée si c'est ce que l'utilisateur charge effectivement depuis les SERPs
• Version HTML classique : mesurée si elle est la version par défaut affichée
• CrUX : collecte les données sur l'URL réelle visitée, pas une version théorique
• Trafic réel : les métriques reflètent l'expérience des vrais utilisateurs, pas des tests en laboratoire
• Cohérence stratégique : optimiser la version que personne ne voit ne sert à rien pour le ranking

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

Oui, et c'est même l'un des rares cas où Google applique exactement ce qu'il dit. Les données CrUX disponibles publiquement montrent clairement que les URLs AMP et non-AMP sont trackées séparément. Si vous comparez les métriques de exemple.com/article et exemple.com/amp/article dans le rapport CrUX, vous verrez deux lignes distinctes avec des performances souvent très différentes.

Ce qui coince, c'est que beaucoup de sites ont supposé qu'optimiser leur version HTML suffirait, alors que 90 % de leur trafic mobile atterrissait sur AMP sans qu'ils le réalisent. Le réveil a été brutal quand les Core Web Vitals sont devenus un facteur de classement — leur version AMP, jamais optimisée, tirait tout le site vers le bas.

Quelles nuances faut-il apporter à cette règle ?

La déclaration de Mueller est claire en surface, mais elle ne dit rien sur les seuils de trafic nécessaires pour qu'une URL soit incluse dans CrUX. Une page avec 10 visites par mois ne génère pas assez de données pour être évaluée — Google se rabat alors sur les métriques au niveau du domaine ou de l'origine.

Autre point flou : que se passe-t-il quand un site propose AMP et HTML classique, mais que les utilisateurs se répartissent 50/50 entre les deux versions ? Google agrège-t-il les scores ? Prend-il la version dominante ? [A verifier] — la documentation officielle reste vague sur ce point, et les retours terrain sont contradictoires.

Dans quels cas cette logique peut-elle créer des problèmes ?

Le cas le plus vicieux : un site qui abandonne AMP sans rediriger proprement les anciennes URLs AMP vers les versions HTML. Si Google continue de servir les URLs AMP en cache (ou si des backlinks pointent dessus), ces pages fantômes continuent d'être mesurées et plombent les Core Web Vitals globaux du domaine.

Autre piège : les sites qui testent leur performance avec Lighthouse ou PageSpeed Insights sur la version HTML, obtiennent des scores parfaits, et ne comprennent pas pourquoi leur classement ne bouge pas. Sauf que leurs utilisateurs réels chargent une version AMP non optimisée — et c'est celle-là que CrUX mesure. Tester la mauvaise version est l'erreur classique ici.

Que faut-il faire concrètement si votre site utilise AMP ?

D'abord, vérifiez quelle version est réellement servie à vos utilisateurs. Consultez vos logs serveur ou Google Analytics filtré sur le trafic organique mobile : combien d'URLs contiennent /amp/ ou un paramètre AMP ? Si c'est la majorité, c'est cette version qu'il faut optimiser en priorité.

Ensuite, testez les Core Web Vitals de votre version AMP avec PageSpeed Insights en collant directement l'URL AMP. Ne vous fiez pas uniquement aux scores de la version HTML — ils ne reflètent pas ce que Google mesure si personne ne la visite. Comparez LCP, CLS et FID entre les deux versions et concentrez vos efforts là où le trafic réel se trouve.

Comment gérer une migration d'AMP vers HTML classique sans perdre en performance ?

Si vous décidez d'abandonner AMP, la transition doit être progressive et surveillée. Retirez d'abord les balises rel="amphtml" de vos pages canoniques pour que Google cesse de proposer la version AMP. Mettez en place des redirections 301 propres des URLs AMP vers les URLs HTML.

Ensuite, surveillez CrUX pendant au moins un mois complet. Les données mettent du temps à basculer — Google continue de mesurer les anciennes URLs AMP tant qu'elles reçoivent du trafic résiduel (backlinks, cache, bookmarks). Si vos Core Web Vitals chutent après la migration, c'est souvent que la version HTML n'est pas aussi performante que vous le pensiez.

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

L'erreur numéro un : optimiser la version que personne ne voit. Avant de lancer un chantier d'optimisation, confirmez quelle URL est majoritairement chargée par vos utilisateurs. Ne partez pas du principe que c'est la version HTML — vérifiez avec des données réelles.

Deuxième piège : croire que les tests en laboratoire (Lighthouse) suffisent. Ces outils mesurent une version théorique dans des conditions idéales. Les données CrUX reflètent le terrain : connexions lentes, appareils bas de gamme, navigateurs obsolètes. Un score Lighthouse de 95 ne garantit pas des Core Web Vitals au vert si vos utilisateurs réels sont sur 3G avec un smartphone d'entrée de gamme.

• Identifiez quelle version (AMP ou HTML) reçoit réellement votre trafic organique
• Testez les Core Web Vitals de la version effectivement servie, pas celle que vous préférez
• Si vous migrez d'AMP vers HTML, mettez en place des redirections 301 propres
• Surveillez CrUX pendant 28 jours après toute migration pour confirmer le basculement
• Ne vous fiez pas uniquement aux scores Lighthouse — consultez les données de terrain CrUX
• Comparez les performances entre desktop et mobile, elles peuvent diverger fortement