AMP ou PWA : quelle technologie choisir pour maximiser vos performances SEO ?

Pourquoi Google oppose-t-il ces deux technologies alors qu'elles cohabitent souvent ?

La déclaration de John Mueller trace une ligne de démarcation nette entre deux approches techniques qui répondent à des problématiques différentes. AMP (Accelerated Mobile Pages) se concentre exclusivement sur la vitesse d'affichage du contenu — un framework ultra-contraint qui supprime tout ce qui ralentit le rendu initial.

Les Progressive Web Apps, elles, misent sur la richesse fonctionnelle : capacités offline via Service Workers, installation sur l'écran d'accueil, notifications push, synchronisation en arrière-plan. Deux philosophies antagonistes qui reflètent deux modèles d'usage web.

Quelle est la différence concrète en termes d'architecture technique ?

AMP impose un HTML restreint, un CSS limité à 50KB inline, et du JavaScript uniquement via des composants validés. Cette rigidité garantit des performances prévisibles — Google peut pré-charger les pages AMP depuis son cache avec une latence quasi-nulle.

Une PWA repose sur un Service Worker qui intercepte les requêtes réseau pour servir du contenu mis en cache. L'architecture reste libre : React, Vue, vanilla JS, peu importe. La complexité augmente proportionnellement aux fonctionnalités — un formulaire multi-étapes avec validation côté client sera trivial en PWA, cauchemardesque en AMP.

Comment cette distinction impacte-t-elle le comportement de Google face à ces contenus ?

Historiquement, AMP bénéficiait d'un traitement préférentiel dans les carrousels Top Stories mobile. Google a officiellement supprimé ce boost en 2021, mais les pages AMP conservent un avantage mécanique : le pré-chargement depuis le cache Google réduit drastiquement le Time to First Byte.

Pour les PWA, aucun traitement spécial côté ranking. Google crawle et indexe comme n'importe quelle page, avec une attention particulière sur les Core Web Vitals — où une PWA bien optimisée peut surperformer grâce au cache applicatif et au chargement progressif.

• AMP privilégie le contenu éditorial : articles, actualités, recettes, fiches produits simples
• PWA excelle sur les parcours complexes : configurateurs, dashboards, applications métier
• Le SEO technique diverge radicalement : canonicalisation stricte en AMP, gestion du cache Service Worker en PWA
• Les métriques de performance s'opposent : FCP/LCP ultra-bas en AMP, TTI/TBT critiques en PWA
• L'effort de maintenance diffère : double publication en AMP (canonical + version AMP), single codebase en PWA

Cette opposition binaire reflète-t-elle la réalité du terrain ?

La dichotomie présentée par Mueller simplifie à l'extrême. Sur le terrain, on observe des hybrides AMP+PWA sur des sites médias majeurs — la page article en AMP pour le trafic cold, la navigation ultérieure en PWA pour la rétention. Ce n'est pas un choix exclusif, c'est une stratégie d'optimisation par couche.

Autre point que Google esquive : AMP a perdu de son lustre depuis 2021. La suppression du badge AMP dans les SERP et la fin du privilège Top Stories ont cassé l'effet réseau. Beaucoup de médias ont abandonné AMP — le ROI technique (maintenance de deux versions) ne compensait plus les gains de trafic.

Quelles sont les limites non-dites de chaque approche ?

AMP bloque des dizaines de cas d'usage : tracking analytics avancé, A/B testing sophistiqué, paywalls dynamiques, login social, widgets tiers. Chaque contournement nécessite un composant amp-custom qui alourdit la stack. [A vérifier] : Google affirme qu'AMP couvre "la publication de contenu", mais ne quantifie jamais la proportion de contenus réellement compatibles sans compromis.

Côté PWA, le point mort est ailleurs : le Service Worker introduit une complexité de cache qui peut générer des bugs vicieux (contenu obsolète servi indéfiniment, désynchronisation entre cache et serveur). Et contrairement au mythe, une PWA mal optimisée sera plus lente qu'un site classique bien ficelé — le overhead du JavaScript reste réel.

Dans quels contextes cette recommandation devient-elle contre-productive ?

Si votre site e-commerce génère 80% de son CA sur des parcours de 5+ pages avec filtres, comparateurs et tunnel de commande, AMP est hors-jeu d'emblée. Inversement, un blog de niche avec zéro interaction (pas de commentaires, pas de newsletter dynamique) n'a objectivement aucun besoin d'une PWA — un site statique généré (Hugo, Jekyll) avec cache CDN agressif fera mieux.

Le vrai sujet que Mueller n'aborde pas : quelle est votre source de trafic dominante ? Si c'est Google Discover ou Top Stories, AMP garde un intérêt tactique. Si c'est du trafic direct ou social avec forte récurrence, la PWA pour favoriser l'installation et les notifications devient stratégique. Le choix est économique avant d'être technique.

Comment arbitrer techniquement entre AMP et PWA pour un projet réel ?

Commence par auditer tes parcours utilisateurs dominants. Si 70%+ de tes sessions sont mono-page (lecture article puis rebond), AMP peut encore avoir du sens — surtout si tu vises les features Google comme Top Stories ou Discover. Analyse tes données GA4 : durée de session, pages par session, taux de retour à 7 jours.

Ensuite, mesure l'écart de performance réel. Fais tourner Lighthouse sur tes pages stratégiques : si ton LCP est déjà sous 2.5s et ton CLS sous 0.1, l'apport AMP sera marginal. Si tu es à 4s+ de LCP, AMP peut diviser ce chiffre par deux — mais optimiser ton site actuel (lazy loading, compression, CDN) pourrait donner le même résultat sans la dette technique.

Quelles erreurs d'implémentation faut-il absolument éviter ?

Erreur classique en AMP : publier une version AMP appauvrie qui casse l'expérience (images manquantes, CTAs absents, contenu tronqué). Google crawle les deux versions — si la version AMP est objectivement dégradée, tu risques de cannibaliser ton taux de conversion sur mobile. La parité fonctionnelle n'est pas négociable.

Côté PWA, le piège récurrent : un Service Worker mal configuré qui cache agressivement du contenu dynamique. Résultat : tes utilisateurs voient des prix obsolètes, des stocks erronés, des articles dépubliés. Implémente une stratégie de cache granulaire (network-first pour les API, cache-first pour les assets) et teste compulsivement les scénarios de mise à jour.

Quelle roadmap adopter si on veut couvrir les deux approches ?

Si tes ressources le permettent, la stratégie AMP pour l'acquisition + PWA pour la rétention reste la plus robuste. Sers une version AMP sur le premier hit (URLs en /amp/ avec canonical vers la version standard), puis charge progressivement les capacités PWA (Service Worker, manifest) dès la deuxième page vue.

Concrètement : un média peut servir ses articles en AMP pour capter le trafic Google, puis installer silencieusement le Service Worker et proposer l'ajout à l'écran d'accueil après 2-3 pages vues. C'est ce que fait The Washington Post — AMP sur les articles, PWA sur la navigation. Mais attention : cette stack hybride nécessite une équipe tech solide et un monitoring serré.

• Cartographie tes typologies de contenu (éditorial statique vs. interfaces interactives)
• Benchmark tes Core Web Vitals actuels sur les pages stratégiques
• Si LCP > 3s ou CLS > 0.15, AMP peut être un quick-win sur le contenu éditorial
• Si ton modèle repose sur engagement/récurrence, priorise PWA avec stratégie de notifications
• Teste en A/B sur un sous-ensemble d'URLs avant de déployer massivement
• Monitore les métriques business (taux de conversion, RPM publicitaire) — la performance technique n'est qu'un proxy