Les Core Web Vitals d'AMP passent-ils par le cache Google ou votre serveur d'origine ?

Pourquoi Google mesure-t-il les performances via le cache AMP et non le serveur d'origine ?

La logique de Google est simple : l'expérience utilisateur réelle prime sur tout le reste. Quand un internaute clique sur un résultat AMP dans les SERP mobiles, il atterrit sur une page servie depuis le cache AMP de Google, pas directement depuis votre infrastructure. C'est cette version — celle qu'il consulte vraiment — dont les performances seront mesurées pour les Core Web Vitals.

Cette approche peut sembler évidente, mais elle a des implications directes pour les SEO qui optimisent leurs serveurs sans prendre en compte l'architecture AMP. Si vos pages AMP sont valides, le cache Google devient le point de livraison final. Vous pouvez avoir un serveur ultra-rapide, un CDN premium, un temps de réponse serveur de 50 ms — tout cela devient secondaire si c'est le cache AMP qui sert la page.

Comment fonctionne exactement le cache AMP de Google ?

Le cache AMP est un système de distribution de contenu géré par Google lui-même. Lorsqu'une page AMP est valide selon les specs, Google la met en cache et la sert directement depuis son infrastructure. Concrètement, l'URL change : votre domaine disparaît au profit d'un domaine Google (cdn.ampproject.org ou google.com/amp/…).

Cette mise en cache apporte généralement des gains de performance substantiels : latence réduite grâce au réseau mondial de Google, compression optimisée, pré-rendu dans certains cas. Mais cela signifie aussi que vous perdez une partie du contrôle sur la livraison. Les headers HTTP, la configuration serveur, les optimisations backend — tout ça devient invisible. Ce que Google mesure, c'est uniquement ce qui arrive au navigateur depuis le cache.

Quelles différences entre les CWV mesurés sur AMP cache vs serveur classique ?

Les Core Web Vitals (LCP, FID, CLS) sont calculés à partir des données de navigation réelles collectées via le Chrome User Experience Report (CrUX). Si vos pages AMP sont majoritairement servies via le cache, c'est cette URL en cache qui apparaît dans CrUX, pas votre URL d'origine.

Cela crée une distinction nette : vos pages classiques (non-AMP) sont évaluées sur votre infrastructure, vos pages AMP sur celle de Google. Les stratégies d'optimisation diffèrent. Sur AMP, vous ne pouvez pas jouer sur le Time to First Byte (TTFB) de votre serveur, ni sur la configuration de votre reverse proxy. En revanche, vous gardez la main sur la structure HTML, le poids des ressources, le JavaScript AMP, et la mise en page (CLS).

• Le cache AMP de Google devient le serveur d'origine effectif pour le calcul des Core Web Vitals si vos pages AMP sont valides.
• Les optimisations serveur classiques (TTFB, gestion des connexions, compression) ne s'appliquent plus sur les pages AMP en cache.
• Le CrUX reporte les données pour l'URL servie au navigateur, donc l'URL en cache AMP, pas votre domaine d'origine.
• Vous conservez le contrôle sur la structure HTML, les ressources embarquées, les images, le CSS AMP, et donc sur LCP et CLS.
• Le FID est généralement excellent sur AMP grâce aux restrictions JavaScript imposées par le format.

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

Oui, et c'est d'ailleurs confirmé par les remontées CrUX. Lorsque vous interrogez l'API CrUX ou PageSpeed Insights pour une URL AMP servie en cache, c'est bien l'URL en cache qui apparaît dans les résultats, pas votre domaine. Google mesure ce que l'utilisateur voit, point final. Pas de double comptage, pas de moyenne entre cache et origine.

Cela dit, beaucoup de praticiens SEO sous-estiment encore cette réalité. Ils optimisent leur backend, réduisent leur TTFB à 30 ms, configurent du HTTP/3 early hints — et se demandent pourquoi leurs pages AMP ne décollent pas dans les Core Web Vitals. La réponse est simple : ces optimisations ne comptent pas si le cache AMP prend le relais. Le gain réel se joue ailleurs : poids des images, structure du DOM, stabilité visuelle.

Quelles nuances faut-il apporter à cette affirmation de Mueller ?

La déclaration est claire, mais elle masque une complexité : toutes les pages AMP ne passent pas systématiquement par le cache. Si votre page AMP contient des erreurs de validation, elle ne sera pas mise en cache par Google. Dans ce cas, c'est votre serveur d'origine qui sert la page, et les Core Web Vitals sont mesurés sur votre infrastructure classique.

Autre point : le cache AMP n'est pas éternel. Il y a une durée de vie (TTL) pour les pages en cache, généralement courte (quelques minutes à quelques heures selon les ressources). Si votre page est peu visitée, elle peut être purgée du cache et recharger depuis l'origine lors de la visite suivante. Dans ce cas, les performances mesurées basculent temporairement vers votre serveur. [A verifier] : Google ne documente pas précisément les règles de TTL et de purge du cache AMP, ce qui rend difficile de prédire quel pourcentage de trafic passe réellement par le cache sur des sites à audience variable.

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

Premier cas évident : pages AMP invalides. Si le validateur AMP remonte des erreurs, votre page ne sera pas mise en cache. Google la servira directement depuis votre serveur, et les Core Web Vitals seront mesurés sur votre infrastructure. C'est un piège classique : une erreur de validation invisible peut faire basculer toute votre stratégie CWV.

Deuxième cas : AMP sur domaine custom avec Signed Exchanges. Depuis l'arrivée des Signed Exchanges (SXG), il est possible de servir des pages AMP depuis votre propre domaine tout en bénéficiant du préchargement Google. Dans cette configuration, c'est votre URL qui s'affiche dans la barre d'adresse, et les Core Web Vitals sont mesurés sur cette URL. Mais attention, SXG impose des contraintes strictes (certificat, headers HTTP, durée de validité) et n'est pas trivial à implémenter.

Que faut-il faire concrètement pour optimiser les CWV sur AMP ?

Première étape : valider que vos pages AMP sont effectivement en cache. Utilisez l'outil de test AMP de Google Search Console ou testez directement une URL en cache (format cdn.ampproject.org). Si des erreurs de validation apparaissent, corrigez-les en priorité. Une page AMP invalide ne sera jamais en cache, donc jamais éligible aux optimisations de performance Google.

Ensuite, concentrez-vous sur les leviers que vous contrôlez réellement : poids des images (utilisez amp-img avec srcset et des formats modernes comme WebP/AVIF), stabilité visuelle (définissez toujours width et height sur les images et iframes pour éviter le CLS), et priorité de chargement (identifiez votre élément LCP et assurez-vous qu'il se charge rapidement, sans être bloqué par des ressources tierces). Oubliez le TTFB, oubliez le backend — ce n'est plus votre problème sur AMP en cache.

Quelles erreurs éviter absolument dans une stratégie AMP axée CWV ?

Erreur n°1 : optimiser le serveur d'origine en ignorant le cache AMP. Investir dans un CDN premium, un serveur ultra-performant, un reverse proxy optimisé — tout cela ne sert à rien si vos pages AMP valides passent par le cache Google. Vous dépensez de l'argent pour optimiser un point de passage que Google contourne.

Erreur n°2 : ne pas monitorer les données CrUX par origine. Si vous avez des pages AMP et non-AMP, vos données CWV seront fragmentées. L'URL en cache AMP et l'URL classique sont deux origines distinctes dans CrUX. Vous devez suivre les deux séparément, sinon vous risquez de mal interpréter vos performances globales. Erreur n°3 : négliger la validation AMP. Une seule erreur de syntaxe suffit à faire basculer une page hors cache, et donc à dégrader vos CWV mesurés sur votre serveur d'origine, potentiellement moins performant.

Comment vérifier que mon site AMP bénéficie bien du cache Google ?

Testez une URL AMP directement dans le validateur AMP officiel (validator.ampproject.org) ou via Google Search Console, section "AMP". Si la page est valide, elle est éligible au cache. Pour confirmer qu'elle est effectivement en cache, recherchez-la dans Google sur mobile et inspectez l'URL servie : si elle commence par cdn.ampproject.org ou google.com/amp/, c'est bon.

Vous pouvez aussi utiliser l'API CrUX pour interroger directement l'URL en cache et vérifier les métriques remontées. Si CrUX ne retourne aucune donnée pour l'URL en cache, soit votre trafic est trop faible (CrUX nécessite un volume minimal), soit la page n'est pas servie en cache. Enfin, surveillez vos Core Web Vitals dans Search Console : si vous voyez deux groupes d'URL distincts (AMP cache vs origine), c'est un signal clair que certaines pages échappent au cache, probablement à cause d'erreurs de validation.

• Valider toutes les pages AMP avec l'outil officiel et corriger les erreurs bloquant la mise en cache.
• Optimiser le poids et le format des images (WebP/AVIF, srcset, lazy loading natif AMP).
• Définir width et height sur tous les éléments visuels pour stabiliser le CLS.
• Identifier l'élément LCP (généralement une image hero) et le prioriser avec fetchpriority="high" si supporté.
• Monitorer séparément les données CrUX pour les URLs AMP en cache et les URLs classiques.
• Ne pas investir dans des optimisations serveur backend pour les pages AMP valides en cache — c'est inutile.