Pourquoi AMP interdit-il le JavaScript personnalisé et comment ça impacte votre SEO ?

Qu'est-ce que cette restriction technique signifie concrètement ?

AMP impose un cadre fermé où le JavaScript custom est purement et simplement banni de l'exécution côté client. Vous ne pouvez pas injecter vos propres scripts pour modifier le DOM, tracker des événements personnalisés ou implémenter des interactions complexes comme vous le feriez sur une page classique.

À la place, Google fournit une bibliothèque de composants préfabriqués (amp-accordion, amp-carousel, amp-analytics, etc.) censés couvrir les besoins courants. Ces composants sont optimisés en amont, leur code est audité et leur comportement prévisible. Le moteur AMP les charge de manière asynchrone et contrôle leur exécution pour éviter les blocages de rendu.

Pourquoi Google justifie-t-il cette contrainte par la performance ?

Le raisonnement officiel tient en une phrase : le JavaScript tiers est la première cause de ralentissement sur les pages web. Scripts analytics mal configurés, bibliothèques jQuery surdimensionnées, trackers publicitaires qui s'empilent, tout ça crée des chaînes de dépendances qui bloquent le rendu et font exploser le Time to Interactive.

En verrouillant l'environnement d'exécution, AMP garantit que chaque élément chargé respecte des budgets de performance stricts. Le framework peut prioriser le contenu visible, différer le chargement des ressources non critiques et maintenir un thread principal réactif. C'est un trade-off radical : sacrifier la flexibilité pour gagner en prévisibilité.

Comment cette approche se traduit-elle dans la pratique SEO ?

Pour un praticien, ça veut dire que migrer une page vers AMP ne se résume pas à ajouter quelques balises. Vous devez refactoriser complètement l'architecture front-end : exit les sliders custom en jQuery, les formulaires avec validation JavaScript complexe, les systèmes de commentaires dynamiques qui ne passent pas par un composant AMP existant.

Certains cas d'usage deviennent impossibles sans contournements lourds. Si votre site e-commerce repose sur un configurateur produit interactif avec logique métier complexe, le portage AMP peut simplement être non viable. La contrainte technique se transforme alors en décision stratégique : est-ce que le gain en vitesse justifie la perte de fonctionnalités ?

• Pas de JavaScript custom exécuté côté client sur les pages AMP
• Composants AMP uniquement pour toute interactivité (accordéons, carrousels, formulaires)
• Performance garantie au prix d'une flexibilité réduite
• Refactoring obligatoire pour migrer des pages existantes vers AMP
• Certains use cases complexes peuvent devenir impossibles à implémenter

Cette déclaration reflète-t-elle vraiment les observations terrain ?

Oui et non. Sur le papier, la logique tient : limiter JavaScript améliore la performance. Les mesures montrent effectivement que les pages AMP chargent plus vite que leurs équivalents non-AMP dans la majorité des cas. Mais cette corrélation n'est pas que technique, elle est aussi politique.

Google a longtemps favorisé AMP dans ses carrousels Top Stories et son affichage mobile. Les éditeurs qui adoptaient AMP gagnaient en visibilité, ce qui créait un biais de sélection : les sites investissant dans AMP étaient aussi ceux qui prenaient la performance au sérieux globalement. Difficile de démêler ce qui relève de l'optimisation AMP stricto sensu et ce qui vient d'une culture de la vitesse déjà présente.

Quelles nuances faut-il apporter à cette position officielle ?

Première nuance : dire que AMP « garantit » une expérience rapide est un peu fort. Un site non-AMP bien optimisé (Critical CSS inline, lazy loading intelligent, JavaScript différé, CDN performant) peut atteindre des scores Core Web Vitals équivalents voire supérieurs. AMP impose des bonnes pratiques, mais il ne détient pas le monopole de la vitesse.

Deuxième nuance : l'interdiction du JavaScript custom crée parfois des contournements absurdes. Certains développeurs chargent des iframes pour contourner la restriction, ou passent par amp-script (qui autorise un JavaScript limité dans un worker isolé) avec des contraintes tellement strictes que le code devient plus complexe qu'une implémentation classique bien pensée. [À vérifier] : dans quelle mesure ces workarounds impactent réellement la performance promise ?

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

Le problème surgit quand le business model entre en collision avec les contraintes AMP. Les sites de média qui vivent de la publicité programmatique doivent jongler avec amp-ad et ses limites. Les plateformes SaaS qui proposent des démos interactives ne peuvent pas les porter en AMP sans les vider de leur substance.

Autre cas épineux : les outils analytics avancés. amp-analytics couvre les basiques (pageviews, clics), mais dès que vous voulez tracker des événements custom complexes (temps passé sur un élément précis, scroll depth par section, interactions avec un élément dynamique), vous vous heurtez aux limitations. Résultat : soit vous simplifiez votre tracking, soit vous abandonnez AMP.

Que faut-il faire concrètement si vous envisagez AMP ?

Commencez par un audit de dépendances JavaScript sur vos pages critiques. Listez tous les scripts actuellement chargés : analytics, A/B testing, chat live, publicité, widgets sociaux, players vidéo. Pour chacun, vérifiez s'il existe un composant AMP équivalent fonctionnel.

Si un script n'a pas d'équivalent AMP et qu'il est business-critical, vous avez trois options : trouver un workaround (souvent lourd), abandonner la fonctionnalité sur AMP, ou renoncer à AMP pour cette typologie de pages. Prenez cette décision avant de commencer à coder, pas après avoir investi des semaines de dev.

Quelles erreurs éviter lors d'une migration AMP ?

Erreur classique : croire que AMP est un simple « mode accéléré » qu'on active en ajoutant des balises. Non. C'est un framework à part entière avec ses propres règles de validation strictes. Un seul script custom oublié, et votre page AMP est invalidée, Google ne la servira pas en cache.

Autre piège : négliger le fallback non-AMP. Beaucoup de sites maintiennent deux versions (AMP et classique) avec rel="amphtml" et rel="canonical". Si vous ne synchronisez pas le contenu entre les deux versions, vous créez du duplicate content et des incohérences qui nuisent au crawl budget et à l'expérience utilisateur.

Comment vérifier que votre implémentation AMP est conforme ?

Utilisez le validateur AMP officiel (validator.ampproject.org) ou l'extension Chrome AMP Validator. Ces outils détectent immédiatement les violations : JavaScript non autorisé, balises interdites, attributs manquants. Aucune page AMP ne passera en cache Google tant qu'elle contient des erreurs.

Testez aussi la performance réelle avec PageSpeed Insights ou WebPageTest. AMP est censé être rapide, mais une page AMP mal conçue (trop d'images lourdes, composants amp-iframe imbriqués, fonts bloquantes) peut rester lente. Validité technique ne signifie pas automatiquement performance optimale.

• Auditer toutes les dépendances JavaScript actuelles avant de migrer
• Vérifier l'existence de composants AMP équivalents pour chaque fonctionnalité
• Utiliser le validateur AMP officiel sur chaque page migrée
• Tester les Core Web Vitals réels post-migration, pas seulement la conformité technique
• Maintenir une synchronisation stricte entre versions AMP et non-AMP
• Documenter les compromis fonctionnels acceptés pour respecter les contraintes AMP