Les pages AMP doivent-elles vraiment respecter les mêmes seuils Core Web Vitals que les pages HTML classiques ?

Pourquoi cette clarification change-t-elle la donne pour AMP ?

Pendant longtemps, les praticiens SEO ont considéré AMP comme un ticket d'entrée automatique pour les performances web. La logique semblait simple : un framework bridé par design, des ressources limitées, donc forcément des métriques au vert.

Cette déclaration de Mueller casse cette idée reçue. AMP n'est pas une carte joker qui dispense d'un audit CWV rigoureux. Google applique exactement les mêmes seuils — 2,5s pour LCP, 100ms pour FID, 0,1 pour CLS — qu'il s'agisse d'une page AMP ou d'une page HTML vanilla avec 3 Mo de JavaScript.

Où se cachent les points de friction sur AMP ?

La majorité des pages AMP respectent effectivement les seuils sans effort particulier. Le framework impose des contraintes strictes : pas de JavaScript custom sans passer par des composants validés, CSS inline limité à 75 Ko, lazy-loading natif sur les images.

Mais trois scénarios créent des problèmes récurrents. D'abord, les publicités tierces : un slot programmatique mal configuré peut faire exploser le CLS même sur AMP. Ensuite, les composants dynamiques type amp-list ou amp-bind qui chargent du contenu après le premier rendu — si la zone n'est pas réservée correctement, le layout shift est garanti. Enfin, les polices web custom mal préchargées qui provoquent du FOIT ou du FOUT visible.

Cette règle s'applique-t-elle à tous les environnements AMP ?

Mueller ne fait aucune distinction entre AMP hébergé en propre et AMP servi depuis le cache Google. Les deux doivent respecter les mêmes seuils CWV. C'est un point important parce que certains pensaient que le cache AMP, avec sa distribution CDN optimisée, pourrait bénéficier d'un traitement plus souple.

Dans les faits, le cache aide énormément — latence quasi nulle, connexions pré-établies — mais ne compense pas un code mal fichu. Une page AMP qui fait 8 secondes de LCP en local fera peut-être 4 secondes depuis le cache, mais restera hors seuil.

• Les pages AMP n'ont aucun traitement de faveur pour les Core Web Vitals — mêmes seuils que HTML classique
• Par défaut, AMP respecte généralement les critères grâce aux contraintes techniques du framework
• Les points d'attention principaux : publicités programmatiques, composants dynamiques, polices web custom
• Le cache AMP améliore les performances mais ne dispense pas d'un code propre côté éditeur
• Un audit CWV reste indispensable même sur AMP, notamment en environnement de production réel

Cette position est-elle cohérente avec le terrain ?

La déclaration de Mueller correspond exactement à ce qu'on observe en production. AMP n'est pas magique — c'est juste un cadre technique qui élimine 90% des erreurs classiques. Les 10% restants dépendent de l'implémentation et peuvent suffire à plomber les métriques.

J'ai audité des sites de presse où 80% des pages AMP étaient conformes CWV, mais les 20% restants — souvent les articles sponsorisés avec beaucoup de pub ou les contenus enrichis type quiz interactif — dépassaient allègrement les seuils. Google ne fait effectivement pas de différence : si le LCP est à 3,2s, la page est classée comme « needs improvement » même si c'est techniquement de l'AMP.

Quelles nuances faut-il apporter sur la facilité de conformité ?

Mueller dit que « par défaut les pages AMP sont généralement assez rapides pour atteindre » les seuils. C'est vrai, mais cette formulation masque une réalité plus complexe. Une page AMP basique — texte, images, structure simple — sera conforme sans effort. Mais dès qu'on ajoute de la personnalisation, des contenus dynamiques ou de la monétisation agressive, la situation se complique.

Le piège classique : migrer un site vers AMP en pensant que ça règle les problèmes de perf, puis réinjecter progressivement des besoins métier (tracking avancé, A/B testing, recommandations temps réel) qui dégradent les métriques. Six mois plus tard, les CWV sont revenus au même niveau qu'avant la migration, sauf qu'on a maintenant deux versions du site à maintenir.

Dans quels cas cette règle pose-t-elle problème ?

Le scénario critique concerne les sites e-commerce sur AMP. Le framework n'a jamais été conçu pour des parcours transactionnels complexes — gestion de panier, filtres multicritères, personnalisation produit. Quand on force ces features dans AMP avec des composants comme amp-bind ou amp-form, les performances se dégradent vite.

Résultat : on se retrouve avec une stack technique bridée qui ne livre ni l'expérience utilisateur souhaitée ni les performances attendues. C'est le pire des deux mondes. Dans ces cas-là, une page HTML classique bien optimisée — code splitting, prefetch intelligent, lazy-loading sélectif — peut donner de meilleurs CWV qu'une page AMP surchargée. [A vérifier] avec des tests A/B sur votre trafic réel avant de généraliser.

Que faut-il auditer en priorité sur vos pages AMP ?

Premier reflexe : sortir les vraies données CWV de la Search Console, filtrées par URL AMP si vous avez une implémentation dual. Les outils lab (Lighthouse, PageSpeed Insights) donnent une première indication, mais les métriques terrain via CrUX sont celles que Google utilise réellement pour le classement.

Concentrez-vous sur trois zones à risque. Les slots publicitaires d'abord — testez avec et sans pour quantifier leur impact réel sur CLS et LCP. Ensuite, les composants dynamiques : tout ce qui charge après le premier rendu doit avoir un espace réservé fixe pour éviter le layout shift. Enfin, les polices custom : utilisez font-display: swap et préchargez les variants critiques avec <link rel="preload">.

Comment corriger les problèmes CWV spécifiques à AMP ?

Pour le LCP, le coupable classique est une image hero non optimisée. Même si AMP gère le lazy-loading, il ne compresse pas les fichiers pour vous. Passez par un CDN image avec compression automatique (WebP/AVIF) et dimensionnement adaptatif. Sur mobile, une image 1200px chargée en full-width alors que le viewport fait 375px, ça tue le LCP.

Pour le CLS, l'astuce est de définir des dimensions explicites sur tous les éléments qui peuvent changer de taille : amp-ad, amp-img, amp-iframe. Si vous utilisez amp-list pour du contenu dynamique, définissez une hauteur minimale avec un skeleton loader. Et testez en condition réelle — souvent, c'est la pub qui ne se charge pas en dev mais explose le CLS en prod.

Quand faut-il envisager d'abandonner AMP ?

Si vous maintenez AMP uniquement pour les performances et que vos pages AMP n'atteignent pas les seuils CWV, la question mérite d'être posée. Soyons honnêtes : maintenir deux versions du site a un coût — développement, tests, synchronisation éditoriale.

Faites le calcul simple. Combien de trafic organique vient réellement sur les URLs AMP ? Si c'est moins de 15% et que les métriques ne sont pas meilleures que la version HTML, vous investissez des ressources pour un gain nul. Dans ce cas, mieux vaut concentrer les efforts sur une seule version hyper-optimisée. Ces optimisations peuvent être complexes à orchestrer seul — analyse des données CrUX, priorisation technique, validation cross-device. Une agence SEO spécialisée en performance web peut vous accompagner pour objectiver les décisions et implémenter les correctifs de manière méthodique.

• Extraire les données CWV réelles (Search Console + CrUX) filtrées par URLs AMP
• Auditer spécifiquement les slots publicitaires et quantifier leur impact CLS/LCP
• Vérifier que tous les composants dynamiques (amp-list, amp-bind) ont des dimensions réservées
• Optimiser les images hero : compression WebP/AVIF + dimensionnement adaptatif mobile
• Configurer font-display: swap et précharger les polices critiques
• Comparer les performances AMP vs HTML classique sur un échantillon représentatif de pages