Le Chrome UX Report compte-t-il vraiment vos pages AMP en cache ?

Pourquoi Google collecte-t-il les données depuis le cache AMP ?

Le Chrome UX Report mesure l'expérience utilisateur réelle (RUM) sur Chrome. Quand un utilisateur accède à votre contenu via une page AMP servie depuis cdn.ampproject.org, c'est cette version en cache qui est mesurée — pas votre page originale.

Cette distinction a un impact direct sur vos Core Web Vitals. Si votre AMP est valide et mise en cache, vous bénéficiez des performances optimisées du cache Google. Si elle est invalide, Google ne peut la servir depuis le cache, l'utilisateur voit votre version canonique, et les métriques CrUX reflètent cette version (souvent moins rapide).

Qu'est-ce qu'une page AMP « valide » selon Google ?

Une page AMP valide respecte toutes les spécifications techniques AMP : balises autorisées, JavaScript interdit sauf composants AMP officiels, CSS inline limité à 75 Ko, etc. Google valide chaque page AMP crawlée avant de la mettre en cache.

Dès qu'une erreur de validation apparaît — une balise non autorisée, un script externe, une erreur de syntaxe —, la page ne peut être servie depuis le cache. L'utilisateur atterrit sur votre version canonique, et c'est cette version que CrUX mesure.

En quoi cela impacte-t-il mes données Core Web Vitals ?

Si votre AMP est valide et en cache, vos métriques CrUX reflètent les performances exceptionnelles du cache Google : LCP ultra-rapide, CLS minimal, FID négligeable. Ces scores gonflent artificiellement vos Core Web Vitals pour les URL AMP.

Mais si votre AMP est invalide, CrUX mesure votre page canonique — probablement plus lourde, plus lente. Vous perdez le bénéfice performance du cache AMP, et vos Core Web Vitals se dégradent. Pire : vous ne savez peut-être même pas que votre AMP est cassée.

• CrUX utilise les données de la version réellement servie : AMP en cache si valide, canonique sinon.
• Une AMP invalide vous prive du boost performance du cache Google dans CrUX.
• Les Core Web Vitals mesurées peuvent différer radicalement entre AMP valide et AMP cassée.
• Google ne vous alerte pas systématiquement si votre AMP devient invalide après publication.
• Vérifiez régulièrement la validité AMP avec l'outil officiel ou Search Console.

Cette déclaration correspond-elle aux observations terrain ?

Oui, et c'est cohérent avec les témoignages de praticiens. Beaucoup ont constaté des écarts massifs de Core Web Vitals entre leurs URL AMP et canoniques. Quand l'AMP est valide et en cache, les métriques CrUX sont au vert ; dès qu'une erreur de validation apparaît, les scores plongent.

Le problème ? Google ne notifie pas toujours immédiatement qu'une AMP est devenue invalide. Vous pouvez passer des semaines à servir une version canonique lente, pensant que votre AMP fonctionne, et voir vos Core Web Vitals se dégrader sans comprendre pourquoi. [À vérifier] : aucune donnée publique ne précise le délai de mise à jour CrUX après invalidation AMP.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller simplifie légèrement. En réalité, le CrUX agrège les données sur 28 jours glissants. Si votre AMP devient invalide en milieu de mois, vos métriques CrUX continueront de mélanger données cache AMP (anciennes) et données canoniques (récentes) pendant plusieurs semaines.

Autre nuance : tous les utilisateurs ne passent pas par le cache AMP. Ceux qui accèdent directement à votre URL canonique (via recherche desktop, partage de lien, etc.) génèrent des données CrUX basées sur cette version, même si votre AMP est valide. CrUX agrège les deux, mais Google ne documente pas précisément le ratio.

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

Si vous n'avez pas de version AMP, cette déclaration est évidemment sans objet. Mais soyons honnêtes : beaucoup de sites ont abandonné AMP depuis que Google a retiré le badge AMP des SERP mobile et élargi l'éligibilité Top Stories aux pages non-AMP.

Si votre site a supprimé ses AMP sans redirection 301 propre, vous pourriez encore avoir des URL AMP indexées qui génèrent des 404 ou des erreurs. Ces pages cassées ne remontent pas dans CrUX, mais elles polluent votre index et créent de la confusion. [À vérifier] : l'impact exact des AMP orphelines sur le crawl budget reste flou.

Que faut-il vérifier concrètement sur vos pages AMP ?

Commencez par auditer la validité de chaque page AMP avec l'outil officiel AMP Validator ou via Search Console (rapport Expérience sur les pages). Une seule erreur suffit à bloquer la mise en cache. Inspectez particulièrement les templates dynamiques : un composant tiers ajouté en production peut casser toutes vos AMP d'un coup.

Ensuite, vérifiez que vos URL AMP apparaissent bien dans CrUX. Consultez le rapport Core Web Vitals de Search Console et comparez les métriques AMP vs canoniques. Si les AMP n'apparaissent pas ou affichent des scores identiques au canonique, elles ne sont probablement pas servies depuis le cache.

Quelles erreurs de configuration cassent le plus souvent les AMP ?

Les coupables classiques : scripts JavaScript tiers intégrés par erreur (analytics non-AMP, publicités custom), balises <style> hors norme, composants AMP obsolètes non mis à jour, CSS inline dépassant 75 Ko, iframes non-AMP, ou balises HTML5 non autorisées (ex : <video> sans composant amp-video).

Autre piège fréquent : les redirections internes mal configurées. Si votre AMP redirige vers le canonique (erreur de paramétrage), Google ne peut la servir en cache, et CrUX mesure le canonique. Résultat : vous perdez le bénéfice performance sans même vous en rendre compte.

Comment monitorer en continu la validité AMP ?

Configurez des alertes Search Console sur le rapport AMP pour être notifié des erreurs de validation. Intégrez le test AMP Validator dans votre pipeline CI/CD : chaque déploiement doit valider automatiquement les templates AMP avant mise en production.

Surveillez également vos métriques CrUX via BigQuery (export gratuit CrUX). Si vous constatez une chute brutale de performance sur vos URL AMP, c'est souvent le signe d'une invalidation récente. Et c'est là que ça devient complexe : diagnostiquer pourquoi une AMP est devenue invalide demande une expertise technique pointue.

• Auditez la validité AMP avec l'outil officiel ou Search Console mensuellement.
• Comparez les Core Web Vitals AMP vs canoniques dans Search Console.
• Supprimez tout script JavaScript tiers non-AMP de vos templates.
• Vérifiez que votre CSS inline reste sous 75 Ko après chaque mise à jour.
• Configurez des alertes Search Console sur le rapport AMP.
• Testez chaque déploiement avec AMP Validator en pré-production.