Pourquoi Google mesure-t-il les Core Web Vitals sur la version de page que vos visiteurs consultent réellement ?

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

Google ne mesure pas les Core Web Vitals sur une version théorique de votre page, mais sur celle que les utilisateurs réels consultent en majorité. Si votre site propose une version AMP et une version HTML classique, le moteur analysera celle qui reçoit le plus de trafic.

Cette logique change la donne pour les sites dual-stack. Jusqu'ici, beaucoup de praticiens pensaient que Google évaluerait systématiquement la version canonique. Faux. La distribution du trafic devient un facteur déterminant dans la mesure de performance qui influencera le ranking.

Comment savoir quelle version sera évaluée pour mon site ?

Regardez vos logs serveur ou votre outil d'analytics : quelle version sert majoritairement vos visiteurs ? Si 70% de votre trafic Google arrive sur l'AMP via le carrousel mobile et 30% sur le HTML desktop, c'est la performance AMP qui comptera dans le calcul des Core Web Vitals.

Le problème, c'est que ce mix peut varier selon les secteurs, les devices, les pays. Un site e-commerce avec une forte audience desktop aura un profil différent d'un média news très mobile. Google ne donne aucun seuil précis : est-ce 51% qui fait basculer ? 60% ? On navigue à vue.

Que révèle cette approche sur la stratégie de Google ?

En se basant sur l'expérience utilisateur réelle, Google aligne ses critères de ranking sur ce que vivent effectivement les internautes. C'est cohérent avec la philosophie des Core Web Vitals : mesurer ce qui impacte vraiment l'UX, pas ce qu'un audit Lighthouse montre en lab.

Cette déclaration confirme aussi que Google continue de pousser l'AMP comme format privilégié pour le mobile. Si votre AMP est majoritaire et performant, vous gagnez. Si elle est majoritaire et lente, vous perdez. Pas de demi-mesure.

• Google mesure la version de page consultée majoritairement par les utilisateurs réels (AMP ou HTML classique).
• La distribution du trafic entre versions devient un facteur indirect de ranking via les Core Web Vitals.
• Aucun seuil précis communiqué pour déterminer quelle version est « majoritaire ».
• Les sites dual-stack doivent auditer leur mix de trafic pour anticiper quelle version sera évaluée.
• Cette approche renforce l'importance d'optimiser la version qui sert réellement le plus de visiteurs, pas forcément la canonique.

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

Oui, et c'est même un rare cas de transparence bienvenue. Google confirme ce que les data CrUX montraient déjà : les métriques remontées proviennent du trafic réel Chrome, pas d'un crawler. Logique que la version majoritairement vue pèse plus lourd.

Par contre, on observe sur certains sites un écart significatif entre la performance AMP et HTML classique. Un client média avait une AMP à 95/100 Lighthouse et un HTML desktop à 62. Si le trafic bascule vers le desktop (changement d'usage, baisse du carrousel AMP), la note Core Web Vitals s'effondre. Google ne dit rien sur la stabilité temporelle de cette mesure.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : Google parle de « version consultée majoritairement », mais ne précise pas l'échelle de temps ni la granularité géographique. Est-ce une moyenne sur 28 jours comme CrUX ? Par device ? Par pays ? [À vérifier] en croisant les données Search Console et CrUX.

Deuxième nuance : cette logique suppose que votre site ait un mix AMP/HTML stable. Si vous lancez une refonte progressive, passant de 20% à 80% de trafic HTML sur 3 mois, la version évaluée va basculer — et potentiellement faire fluctuer votre ranking pendant la transition. Aucune communication officielle sur ce cas de figure.

Dans quels cas cette règle pourrait-elle créer des effets de bord ?

Imaginez un site avec une AMP ultra-rapide mais un HTML desktop pourri. Tant que le trafic mobile domine, tout va bien. Le jour où Google modifie l'affichage du carrousel AMP (ça arrive) ou qu'un concurrent desktop gagne des parts, le trafic bascule — et vos Core Web Vitals plongent.

Autre cas : les sites avec des parcours utilisateurs complexes (progressive web app, single page application). Google ne dit rien sur les sessions multi-pages ou les navigations AJAX. Si un user charge l'AMP puis navigue en HTML via un lien interne, quelle version compte ? Silence radio.

Que faut-il faire concrètement pour s'assurer de mesurer la bonne version ?

Premier réflexe : segmentez votre trafic dans Google Analytics ou votre outil de logs. Créez des segments « AMP » vs « HTML classique » et calculez la répartition sur les 28 derniers jours (période de référence probable de CrUX). Si la distribution est 70/30, vous savez sur quelle version concentrer vos efforts d'optimisation.

Ensuite, croisez avec les données CrUX via PageSpeed Insights ou BigQuery. Vérifiez que les métriques LCP, FID, CLS remontées correspondent bien à la version majoritaire. Si vous voyez un écart entre vos mesures RUM internes et CrUX, c'est peut-être que Google évalue une version différente de celle que vous pensiez.

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

Erreur classique : optimiser uniquement la version canonique en pensant que c'est elle qui comptera. Si votre canonical est en HTML mais que 80% du trafic arrive sur l'AMP, vous passez à côté du sujet. Auditez d'abord le mix réel avant d'investir des ressources.

Deuxième piège : négliger la cohérence des parcours. Un user qui atterrit sur une AMP rapide puis clique vers une page HTML lente vivra une expérience dégradée — et Google le verra dans les métriques de session. Pensez parcours complet, pas page isolée.

Comment suivre l'évolution de cette répartition dans le temps ?

Mettez en place un tableau de bord automatisé qui track le ratio AMP/HTML par semaine. Si vous observez un basculement (ex : passage de 60/40 à 40/60), anticipez l'impact sur vos Core Web Vitals avant que le ranking ne bouge.

Surveillez aussi les annonces Google sur l'évolution de l'affichage AMP (carrousel, stories, etc.). Un changement dans la présentation des résultats peut redistribuer le trafic entre versions — et donc modifier la version évaluée pour les Core Web Vitals.

• Segmentez votre trafic Analytics pour identifier la version majoritairement consultée (AMP vs HTML).
• Croisez ces données avec les métriques CrUX pour vérifier la cohérence.
• Optimisez en priorité la version qui sert le plus de trafic réel, pas forcément la canonique.
• Ne négligez pas la version minoritaire : 40% de visiteurs avec une expérience dégradée, ça reste un problème business.
• Automatisez le suivi du ratio AMP/HTML pour anticiper les basculements.
• Testez les Core Web Vitals sur les deux versions en conditions réelles (devices, réseaux, géos).