Comment Google attribue-t-il désormais les données CrUX du cache AMP à l'origine ?

Qu'est-ce que cette consolidation des données CrUX change pour le cache AMP ?

Jusqu'ici, les données CrUX du cache AMP étaient traitées séparément de celles de votre origine principale. Le cache AMP de Google servait vos pages depuis ses propres serveurs (cdn.ampproject.org), ce qui créait une origine technique distincte. Résultat : vos métriques de performance étaient fragmentées.

Désormais, Google attribue ces données à votre origine canonique. Si un utilisateur charge votre article via le cache AMP, ses métriques Core Web Vitals (LCP, FID, CLS) remontent dans le rapport CrUX de votre domaine principal. Fini la séparation artificielle.

Pourquoi la canonicalisation correcte est-elle la clé ?

Google insiste sur un point crucial : la canonicalisation doit être bidirectionnelle. Votre page AMP doit pointer vers la version non-AMP via <link rel="canonical">, et vice-versa avec <link rel="amphtml">. Sans cette configuration, Google ne peut pas faire le lien entre les deux versions.

En pratique, une canonicalisation bancale était déjà problématique pour l'indexation. Maintenant, elle vous prive aussi de la consolidation des métriques CrUX. Si vos pages AMP génèrent du trafic significatif mais que les balises canonical sont cassées, vos données de performance restent orphelines.

Quelles métriques CrUX sont concernées par cette attribution ?

Toutes les Core Web Vitals du dataset CrUX sont agrégées : Largest Contentful Paint, First Input Delay (ou Interaction to Next Paint), Cumulative Layout Shift, First Contentful Paint, Time to First Byte. Ces données proviennent des utilisateurs Chrome réels, collectées sur les 28 derniers jours glissants.

L'impact est direct sur votre évaluation Page Experience. Google utilise CrUX pour déterminer si vos pages respectent les seuils "bons" des Core Web Vitals. Si vos pages AMP sont ultra-performantes (ce qui est souvent le cas grâce aux contraintes du format), elles peuvent compenser des versions desktop ou mobile plus lentes.

• Les données CrUX du cache AMP sont désormais comptabilisées dans les métriques de votre origine principale
• La canonicalisation bidirectionnelle (AMP vers non-AMP et inversement) est obligatoire pour que l'attribution fonctionne
• Toutes les Core Web Vitals sont concernées, avec un impact direct sur l'évaluation Page Experience
• Le trafic AMP performant peut désormais booster vos métriques globales CrUX au lieu de rester isolé
• Les 28 jours glissants du dataset CrUX incluent maintenant les données des deux versions si la config est correcte

Cette annonce règle-t-elle vraiment le problème historique de fragmentation AMP ?

Soyons honnêtes : c'est un ajustement technique attendu depuis longtemps. La séparation des origines AMP/non-AMP était un artefact architectural qui n'avait aucun sens côté UX. Un utilisateur consulte votre contenu, peu importe que Google le serve depuis son cache ou votre serveur.

Mais voilà le hic — [À vérifier] : Google ne précise pas la pondération appliquée quand les métriques divergent fortement entre AMP et non-AMP. Si 70% de ton trafic mobile vient du cache AMP ultra-rapide et 30% de ta version mobile standard plus lente, comment CrUX agrège-t-il ? Ratio proportionnel au volume de trafic réel ? Moyenne arithmétique ? Aucune clarification.

Dans quels cas cette consolidation peut-elle fausser ton diagnostic de performance ?

Imagine que tes pages AMP affichent un LCP de 1,2 seconde (excellent) mais que ta version mobile non-AMP plafonne à 3,8 secondes (médiocre). Après consolidation, ton rapport CrUX global peut afficher un LCP "moyen" de 2,0-2,5 secondes, selon la répartition du trafic.

Le risque ? Masquer des problèmes de performance réels sur ta version principale. Tu peux passer au vert dans CrUX grâce à l'effet de levier AMP, tout en laissant ton site mobile standard ramer. Pour un audit précis, tu dois désormais croiser les données CrUX de l'origine avec les métriques de ton RUM (Real User Monitoring) par type de page.

Google est-il cohérent avec sa stratégie long-terme sur AMP ?

Cette annonce intervient alors que AMP n'est plus un prérequis pour le Top Stories depuis 2021. Google a dépriorisé le format, reconnaissant que les Core Web Vitals seules suffisent. Consolider les données CrUX, c'est admettre implicitement que la fragmentation des origines était une erreur de conception.

Paradoxalement, cela peut redonner de l'intérêt à AMP — non plus comme format imposé, mais comme optimiseur de métriques CrUX. Si tu maintiens AMP pour une partie de ton trafic (notamment mobile), tu bénéficies d'un boost de performance agrégé. Stratégie viable ? Oui, si tu as les ressources pour maintenir deux versions. Sinon, mieux vaut optimiser ta version unique.

Que faut-il vérifier en priorité sur ta configuration AMP ?

Premier réflexe : audite tes balises canonical. Crawle ton site avec Screaming Frog ou Oncrawl en isolant les pages AMP. Vérifie que chaque page AMP contient <link rel="canonical" href="https://tonsite.com/page"> pointant vers la version non-AMP. Puis vérifie l'inverse : chaque page non-AMP doit avoir <link rel="amphtml" href="https://tonsite.com/page/amp">.

Ensuite, contrôle dans Search Console que Google indexe bien les bonnes canoniques. Va dans Couverture > Exclues > "Page alternative avec balise canonical appropriée". Tes pages AMP doivent y figurer, confirmant que Google comprend la hiérarchie. Si elles apparaissent dans les pages indexées, tu as un problème de canonicalisation.

Comment mesurer l'impact réel de cette consolidation CrUX ?

Compare tes données CrUX avant/après dans PageSpeed Insights ou le rapport Core Web Vitals de Search Console. Note la date de déploiement de cette modification par Google, puis observe l'évolution des métriques sur les 28 jours suivants (durée de la fenêtre CrUX).

Installe également un monitoring RUM segmenté (Google Analytics 4 avec Web Vitals ou un outil comme SpeedCurve). Filtre tes données par type de page (AMP vs non-AMP) pour comprendre la contribution réelle de chaque version à tes métriques globales. Si AMP représente 5% du trafic, l'impact sera marginal. S'il pèse 40%+, c'est significatif.

Faut-il maintenir AMP uniquement pour optimiser CrUX ?

Question légitime. Si ton trafic AMP est conséquent (typiquement médias, actualité, recettes) et que tes versions AMP surperforment largement, conserver le format a du sens. Tu gagnes des points CrUX sans effort, puisque AMP impose déjà des contraintes de performance strictes.

Par contre, si tu génères <10% de trafic AMP ou que maintenir deux versions bouffe tes ressources, abandonne. Investis plutôt dans l'optimisation de ta version unique : lazy-loading, CDN, compression images, critical CSS, preconnect. Une page bien optimisée peut égaler ou surpasser AMP sans la dette technique de deux codebases.

Ces optimisations — canonicalisation rigoureuse, monitoring RUM segmenté, arbitrage stratégique AMP — demandent une expertise technique solide et du temps de dev. Si ton équipe manque de bande passante ou de compétences Core Web Vitals, faire appel à une agence SEO spécialisée peut accélérer la mise en conformité. Un audit externe identifie rapidement les points de blocage et priorise les chantiers à ROI immédiat.

• Auditer la canonicalisation bidirectionnelle AMP/non-AMP avec un crawler SEO
• Vérifier dans Search Console que les pages AMP sont bien traitées comme alternatives canoniques
• Comparer les métriques CrUX avant/après consolidation sur une fenêtre de 28 jours minimum
• Installer un monitoring RUM segmenté pour isoler la contribution AMP vs non-AMP
• Arbitrer le maintien ou l'abandon d'AMP en fonction du volume de trafic et des ressources disponibles
• Optimiser prioritairement la version non-AMP si AMP représente moins de 10% du trafic