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

Pourquoi Google parle-t-il de « données de terrain » ?

Les données de terrain (field data) reflètent l'expérience réelle des utilisateurs, mesurée via le Chrome User Experience Report (CrUX). Contrairement aux tests en laboratoire (Lighthouse, PageSpeed Insights en mode « lab »), ces métriques capturent ce que vivent réellement vos visiteurs : connexions 3G instables, terminaux bas de gamme, contextes de navigation variés.

Le point crucial ici : Google ne se base pas sur une moyenne théorique. Il regarde quelle version de votre page les utilisateurs ont effectivement chargée depuis les résultats de recherche. Si c'est une page AMP qui s'affiche, les CWV sont calculés sur cette version AMP, point final.

Quelle différence cela fait-il entre AMP et mobile web classique ?

Les pages AMP (Accelerated Mobile Pages) sont conçues pour être ultra-rapides : HTML épuré, JavaScript limité, ressources préchargées par le cache Google. Leurs scores CWV sont généralement meilleurs que ceux des pages mobile standard. Mais si vous servez du mobile web classique dans les SERP, c'est cette version — souvent plus lourde, plus riche en scripts — qui sera évaluée.

Concrètement ? Vous pouvez avoir une page AMP avec d'excellents CWV, mais si Google affiche votre version mobile web aux utilisateurs, vos scores CWV reposent sur cette dernière. L'inverse est tout aussi vrai : une page mobile lente ne pénalisera pas vos CWV si seule la version AMP est indexée et servie.

Comment savoir quelle version Google utilise pour mes CWV ?

Première étape : vérifiez dans la Search Console quels URLs sont indexés. Si vous avez implémenté AMP avec la balise rel="amphtml", Google peut choisir de servir l'une ou l'autre version selon le contexte. Historiquement, AMP était privilégié dans les carrousels « Top Stories », mais depuis la fin de cette exclusivité, le choix dépend de multiples signaux.

Ensuite, consultez le rapport Core Web Vitals dans la Search Console. Les URLs listés correspondent aux pages réellement évaluées. Si vous voyez des URLs AMP, ce sont ces versions qui comptent. Si ce sont vos URLs canoniques standard, idem. Pas de mystère — mais il faut vérifier factuellement, ne pas supposer.

• Les CWV reposent sur les données CrUX, donc sur l'expérience réelle des utilisateurs Chrome.
• La version servie dans les SERP détermine les métriques : AMP si AMP affiché, mobile web si mobile web affiché.
• Pas de « moyenne » entre versions : Google ne mixe pas les scores AMP et non-AMP pour un même contenu.
• Vérifiez toujours dans la Search Console quels URLs sont évalués pour les CWV.
• L'abandon progressif du cache AMP par Google complique encore la donne : certaines pages AMP sont désormais servies depuis l'origine, avec des temps de chargement différents.

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

Absolument. Les audits que je mène depuis des années confirment ce mécanisme. J'ai vu des sites avec d'excellents scores Lighthouse en « lab » afficher des CWV catastrophiques en production parce que les conditions réelles (latence réseau, CPU mobile limité) n'ont rien à voir avec un test sur desktop fibre. Google ne ment pas ici : seule compte l'expérience utilisateur mesurée.

Le piège classique ? Optimiser sa page desktop ou mobile en conditions idéales, puis découvrir que la version AMP, négligée, plombe les scores CWV parce qu'elle reste servie à une partie du trafic. Ou l'inverse : peaufiner l'AMP alors que Google a basculé vers le mobile web canonique. Soyons honnêtes : beaucoup de SEO ne vérifient pas quelle version est réellement évaluée.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : CrUX a un seuil de trafic minimum. Si votre page n'a pas assez de visiteurs Chrome sur 28 jours glissants, elle n'apparaît pas dans CrUX, donc pas de données CWV au niveau URL. Google remonte alors au niveau origine (domaine entier), ce qui dilue les performances réelles d'une page spécifique. [A vérifier] pour les sites à trafic faible ou très segmenté.

Deuxième point : la transition progressive vers le « signed exchange » (SXG) pour AMP modifie la donne. Avec SXG, la page AMP peut être servie depuis votre domaine tout en bénéficiant du préchargement Google. Les métriques CWV reflètent alors un mix entre cache et origine, selon le navigateur et le contexte. Ce n'est pas une généralité — tout le monde n'a pas migré vers SXG — mais ça ajoute une couche de complexité.

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

Si vous avez abandonné AMP ou si vous n'en avez jamais implémenté, cette distinction n'a aucun impact : vous n'avez qu'une seule version mobile, donc une seule source de données CWV. Pas de double tracking à gérer. Le problème se pose surtout pour les sites hybrides qui maintiennent AMP et mobile web en parallèle, sans stratégie claire sur quelle version prioriser.

Autre cas limite : les sites avec rendu côté client (SPA, JavaScript lourd). Même si Google affiche votre URL canonique dans les SERP, l'expérience utilisateur mesurée par CrUX peut être catastrophique si le FCP (First Contentful Paint) ou le LCP (Largest Contentful Paint) sont retardés par des frameworks mal optimisés. Là, la déclaration de Mueller reste valide, mais elle masque un problème architectural plus profond. [A vérifier] : est-ce que Google pénalise davantage les SPA lourdes via CWV, ou applique-t-il un traitement identique ? Les données publiques manquent pour trancher définitivement.

Que faut-il faire concrètement pour aligner CWV et version servie ?

Première action : auditer la Search Console pour identifier quels URLs sont listés dans le rapport Core Web Vitals. Si vous voyez un mélange d'URLs AMP et canoniques, vous avez un problème de cohérence. Google sert visiblement les deux versions selon le contexte, ce qui fragmente vos efforts d'optimisation.

Ensuite, testez les deux versions avec PageSpeed Insights en mode « field data ». Ne vous fiez pas uniquement aux scores « lab » (Lighthouse) : ils ne reflètent pas les conditions réelles. Si vos données CrUX montrent des écarts significatifs entre AMP et mobile web, c'est le signal qu'il faut prioriser l'une ou désactiver l'autre. Garder deux versions médiocres ne sert à rien.

Quelles erreurs éviter dans la gestion AMP vs mobile web ?

Erreur classique : laisser traîner une implémentation AMP obsolète. Beaucoup de sites ont lancé AMP en 2016-2018 pour profiter du carrousel Top Stories, puis l'ont abandonnée côté éditorial sans supprimer les balises rel="amphtml". Résultat : des pages AMP zombies, non maintenues, avec des CWV catastrophiques, continuent d'être servies sporadiquement.

Autre piège : optimiser uniquement le mobile web en supposant qu'AMP est « automatiquement rapide ». Faux. Une page AMP mal codée (images non optimisées, trop de composants amp-script, fonts custom lourdes) peut avoir des LCP déplorables. Le cadre AMP impose des limites, mais ne garantit rien si vous ne suivez pas les bonnes pratiques.

Comment vérifier que mon site est conforme et bien configuré ?

Utilisez l'outil AMP Test de Google pour valider vos pages AMP : erreurs de balisage, composants obsolètes, ressources bloquées. Ensuite, comparez les données CrUX (via PageSpeed Insights ou BigQuery) entre vos URLs AMP et canoniques. Si l'écart de performance est marginal, désactiver AMP simplifie votre stack technique sans perte SEO notable.

Vérifiez aussi vos balises canoniques et amphtml : elles doivent pointer réciproquement de manière cohérente. Une erreur de pointage peut induire Google en confusion sur la version à indexer et servir. Enfin, surveillez les rapports « Expérience sur la page » dans la Search Console : si des URLs AMP y figurent alors que vous pensiez les avoir désactivées, c'est qu'il reste des traces (sitemaps, liens internes, balises résiduelles).

• Auditer le rapport Core Web Vitals de la Search Console pour identifier les URLs évalués (AMP ou canonique).
• Comparer les données CrUX field entre versions AMP et mobile web via PageSpeed Insights.
• Désactiver AMP proprement si les gains de performance sont négligeables (suppression balises amphtml, redirection 301, mise à jour sitemaps).
• Optimiser en priorité la version effectivement servie dans les SERP, pas celle que vous « croyez » servir.
• Surveiller les évolutions CrUX mensuellement : les comportements utilisateurs changent, les métriques aussi.
• Tester régulièrement avec des outils terrain (WebPageTest en conditions mobiles réelles, CrUX API) pour éviter les surprises.