# AMP en 2026 : pourquoi mon site l'utilise encore, et ce que ça coûte

> Depuis le 1er juillet 2026, Google n'envoie plus ses visiteurs vers le cache AMP. Le dernier privilège du format vient de tomber. Mon site reste en AMP, et voici, mesures à l'appui, ce que ce choix rapporte encore et ce qu'il coûte.


*Ou : Comment garder un passe-droit après la fermeture du guichet*

Depuis le 1er juillet 2026, un clic sur un résultat AMP dans Google mène directement sur le site de l'éditeur, comme n'importe quelle page. Le cache AMP de Google, qui servait ces pages depuis ses propres serveurs, ne sert plus la recherche. C'était le dernier avantage réservé au format : le badge et l'exigence d'AMP pour le carrousel d'actualités avaient disparu en 2021. Il ne reste donc, en 2026, aucun bonus de classement, aucune vitrine réservée, aucune livraison accélérée. Et pourtant, ce site tourne entièrement en AMP, 580 pages, toutes valides au 4 octobre 2026. Les avantages et les inconvénients d'AMP en 2026 ne se lisent plus dans les annonces de Google. Ils se mesurent, page par page, et la mesure n'est pas toujours flatteuse.

Cet article fait le tri en quatre temps : l'histoire en cinq dates, ce que le format ne t'apporte plus chez Google, ce qu'il apporte encore, et la facture, mesurée sur ce site avec les outils que tout le monde peut lancer. Un tableau compare ensuite AMP à une page HTML classique bien optimisée, critère par critère.

## Avantages et inconvénients d'AMP en 2026 : ce qui reste quand Google retire ses faveurs
{.subtitle}

### Cinq dates, et un passe-droit qui s'efface

AMP, pour *Accelerated Mobile Pages*, a été présenté par Google le 7 octobre 2015 comme un projet libre destiné à rendre le web mobile instantané, avec une trentaine d'éditeurs partenaires au lancement[^1]. Le principe tenait en trois pièces : un HTML restreint, un moteur d'exécution JavaScript unique fourni par le projet, et des caches qui pouvaient servir les pages valides depuis leurs propres serveurs. En échange, Google mettait ces pages en avant. C'est cette contrepartie qui a fait le succès d'AMP, et c'est elle qui s'est effacée, étape par étape.

| Date | Événement |
|---|---|
| 7 octobre 2015 | Google annonce le projet AMP[^1] |
| Septembre 2018 | Bing lance son propre visualiseur et son cache AMP[^2] |
| 10 octobre 2019 | AMP rejoint le programme d'incubation de l'OpenJS Foundation, avec plus de 30 millions de domaines revendiqués[^3] |
| 19 avril 2021 | Google annonce la fin de l'exigence AMP pour le carrousel d'actualités et du badge AMP, effective à partir de mi-juin 2021[^4] |
| 1er juillet 2026 | Google cesse de servir les résultats AMP depuis son cache et retire de sa documentation le visualiseur, le cache et les échanges signés[^5] |

Le projet, lui, n'est pas mort. Son dépôt reçoit encore des correctifs, et la dernière version stable du moteur date du 18 août 2026[^6]. Mais un projet vivant n'est pas un projet favorisé, et la nuance compte pour qui choisit sa technologie en 2026.

### Ce qu'AMP ne fait plus pour toi chez Google

La phrase d'avril 2021 mérite d'être relue lentement. Google y écrivait que le format AMP n'était plus requis, et que toute page, « irrespective of its Core Web Vitals score or page experience status », devenait éligible au carrousel d'actualités[^4]. Autrement dit, la vitrine qu'AMP réservait à ses pages s'ouvrait à toutes, rapides ou non. Le badge, ce petit éclair qui signalait les pages AMP dans les résultats, disparaissait dans le même mouvement.

La documentation actuelle de Google, mise à jour le 1er juillet 2026, enfonce le clou : la recherche indexe les pages AMP « just like other web pages », et applique le même standard à toutes, quelle que soit la technologie employée[^5]. Elle précise aussi que l'adresse visible après un clic est désormais celle de ta page AMP, comme pour n'importe quel site. Il n'y a plus de `google.com/amp/` dans la barre d'adresse, plus de chargement anticipé depuis les serveurs de Google, plus d'échanges signés à configurer.

Reste Bing. La documentation d'AMP cite toujours deux caches, celui de Google et celui de Bing[^7], mais je n'ai trouvé aucune documentation récente de Bing sur l'usage qu'il en fait aujourd'hui. Je ne vais donc pas te promettre un avantage que personne ne documente.

Côté référencement, le bilan est simple : AMP ne t'apporte plus rien que les autres pages n'aient pas. Il ne te retire rien non plus. Le choix d'AMP en 2026 n'est donc plus un choix de référencement, c'est un choix d'architecture.

![Illustration d'un rideau de théâtre fermé sur une scène sombre, avec un sablier de laiton posé au pied du rideau dans une lumière ambrée](/images/amp-2026-avantages-inconvenients-rideau.original.webp "Le code d'amorçage d'AMP garde le rideau fermé jusqu'à l'arrivée du moteur, huit secondes au plus.")

### Ce que fait réellement le thème de ce site

Avant de parler d'avantages, voici ce que fait le thème, concrètement. Chaque page commence par `<html amp>`, embarque le code d'amorçage imposé par la spécification, charge le moteur `v0.js` depuis `cdn.ampproject.org`, puis quatre extensions sur toutes les pages : `amp-sidebar` pour le menu mobile, `amp-consent` pour le bandeau de consentement, `amp-form` et `amp-mustache` pour les formulaires. La page d'accueil ajoute `amp-video`, et les articles qui intègrent une vidéo ajoutent `amp-youtube`. Toutes les images passent par `amp-img`, avec des dimensions déclarées. Tout le CSS tient dans un seul fichier du thème, injecté dans l'en-tête de chaque page.

Ce thème sert tout le site : le blog, les guides, le glossaire, les projets. C'est l'une de mes raisons de rester en AMP : maintenir un seul thème, avec les mêmes règles de rendu partout, est plus simple qu'un mélange de pages AMP et de pages classiques, et garantit la même cohérence visuelle et technique d'une section à l'autre. Le format est arrivé avec la [migration de mes sites WordPress vers Hugo](/blog/migration-wordpress-hugo/), et l'autre raison était la vitesse ressentie sur mobile. On va voir que la mesure apporte de la nuance sur ce second point.

### Les avantages qui survivent à la fin des faveurs

Le premier avantage est un budget que personne ne peut dépasser. AMP plafonne le CSS d'une page à 75 000 octets, styles inline compris[^8]. Sur ce site, au 4 octobre 2026, la médiane est de 43 283 octets et la page la plus lourde, une entrée du glossaire, atteint 44 213 octets. Ce budget m'a déjà rattrapé une fois, quand la coloration syntaxique a fait grimper une page à 94 225 octets : l'histoire est racontée dans [la limite CSS d'AMP et le correctif de Hugo](/blog/hugo-amp-limite-css-chroma-noclasses/). Sans ce plafond, la page aurait gardé ses 50 Ko de styles répétés, et personne ne l'aurait remarqué. Le plafond a fait son travail de garde-fou.

Le deuxième avantage est l'absence de saut de mise en page. `amp-img` exige des dimensions, et le moteur réserve la place de chaque image avant qu'elle arrive. Résultat sur la page la plus chargée du blog : un CLS de 0 aux trois passages de Lighthouse. C'est l'indicateur de stabilité visuelle des Core Web Vitals, dont le seuil acceptable est fixé à 0,1[^9]. AMP ne rend pas les pages rapides par magie, mais il rend certaines erreurs impossibles à commettre.

Le troisième avantage est le plus sous-estimé : un validateur officiel qui répond par oui ou par non. J'ai fait passer les 580 pages AMP du site, construites localement, dans `amphtml-validator` le 4 octobre 2026 : 580 réussites, aucune erreur. C'est l'équivalent d'une suite de tests pour le gabarit, avec la même vertu que [les tests dans une stratégie complète](/blog/strategie-test-complete-go/) : le verdict est binaire, il ne dépend pas d'une humeur ni d'un score moyen. Lighthouse t'attribue une note. Le validateur te dit si ta page respecte le contrat.

Le quatrième avantage est un effet de bord : sans JavaScript d'auteur, il n'y a pas de JavaScript d'auteur à maintenir. Aucun script maison à mettre à jour, aucune bibliothèque tierce glissée dans un gabarit pour un effet de survol, aucune dépendance npm à surveiller. Ce n'est pas un argument de vitesse, c'est un argument de surface.

### La facture, mesurée sur ce site

Pour la facture, j'ai lancé Lighthouse 12.8.2 trois fois, le 4 octobre 2026, sur [l'article consacré à l'injection SQL en Go](/blog/gorm-injection-sql-golang/), en production. Le profil est celui de Lighthouse pour le mobile : une connexion 4G lente simulée et un processeur ralenti quatre fois. C'est un profil sévère, volontairement. Les chiffres ne disent pas ce que vit un lecteur sur fibre, ils disent où le temps part quand les conditions se dégradent.

| Mesure, profil mobile | Résultat |
|---|---|
| Requêtes | 21, pour 565 Kio transférés |
| JavaScript | 8 requêtes, 159 Ko, tout fourni par AMP |
| Premier affichage (FCP) | 3,6 s |
| Plus grand élément affiché (LCP) | 4,5 à 4,9 s, pour un seuil acceptable de 2,5 s |
| Stabilité visuelle (CLS) | 0 |
| Temps de blocage total | 50 à 70 ms |

Commence par le JavaScript. AMP interdit le JavaScript d'auteur, mais il en charge beaucoup pour son propre compte. Le moteur `v0.js` pèse 73 Ko compressés, 285 Ko une fois décompressé, et le moteur charge de lui-même trois extensions que le thème ne déclare pas : `amp-auto-lightbox`, `amp-lightbox-gallery` et `amp-loader`. Au total, la page transfère 159 Ko de JavaScript, plus du double du plafond CSS qu'AMP surveille si jalousement, et près de quatre fois le CSS réel de la page. La règle interdit ton code, pas le sien.

Viennent ensuite les 3,6 secondes du premier affichage. Le code d'amorçage d'AMP masque le corps de la page jusqu'à ce que le moteur soit prêt, avec un délai de secours de huit secondes[^10]. Tant que `v0.js` n'est pas arrivé, il n'y a rien à voir, même si le HTML est déjà là. Et si `cdn.ampproject.org` répond mal, le lecteur regarde une page blanche jusqu'à huit secondes avant que le texte n'apparaisse. C'est la dépendance la plus discrète d'AMP : un domaine tiers dans le chemin critique de chaque page.

Le reste de la facture, en revanche, n'est pas d'AMP, et l'honnêteté oblige à le dire. Les images pèsent 250 Ko, les polices 127 Ko, dont 78 Ko pour la seule police d'icônes Font Awesome, et deux feuilles de style externes, celles des polices, bloquent le rendu. Un site HTML classique avec les mêmes polices et les mêmes images paierait cette partie-là exactement pareil. AMP n'est pas responsable de tout ce qui est lent sur une page AMP. Il est responsable du moteur, du rideau d'amorçage et de l'interdiction de faire autrement.

Dernier poste : la liberté. Tout ce qui est interactif passe par un composant `amp-*`, ou par `amp-script`, qui exécute du JavaScript dans un Web Worker avec des plafonds stricts : 10 000 octets par script inline, 150 000 octets par page hors bac à sable[^11]. `!important` est interdit, et les feuilles de style externes ne sont admises que pour une courte liste de fournisseurs de polices[^12]. Le jour où tu veux un composant que le catalogue AMP n'a pas, tu le reconstruis dans ces limites ou tu t'en passes.

### AMP contre une page HTML optimisée, ligne par ligne

| Critère | AMP en 2026 | HTML classique optimisé |
|---|---|---|
| Classement Google | Même traitement que toute page | Même traitement que toute page |
| Cache et livraison par Google | Fin le 1er juillet 2026 | Sans objet |
| JavaScript | Moteur imposé, 159 Ko sur la page mesurée ; ton code seulement dans `amp-script` | Libre ; à toi de le limiter |
| CSS | 75 000 octets au plus, dans la page, sans `!important` | Libre, en fichiers externes mis en cache |
| Images | `amp-img` avec dimensions obligatoires, CLS à 0 sans effort | `img` avec `width`, `height` et chargement différé, à discipliner soi-même |
| Premier affichage | Attend le moteur, secours à 8 s | Dès que le HTML et le CSS critique arrivent |
| Validation | Validateur officiel, verdict binaire | Audits à score, pas de verdict binaire |
| Dépendance externe | `cdn.ampproject.org` dans le chemin critique | Aucune imposée |
| Core Web Vitals | Mesurés comme ceux de toute page | Mesurés comme ceux de toute page |

Lu de haut en bas, le tableau raconte une chose : les deux colonnes sont désormais à égalité devant Google, et elles diffèrent seulement par ce qu'elles t'autorisent à faire. AMP retire des libertés, et chaque liberté retirée est à la fois une erreur évitée et une option perdue.

### Le jour où Dave voulait un module de discussion

**DevOps Dave :** Je veux ajouter un petit script de discussion en bas des articles. Trois lignes, copiées depuis la documentation du fournisseur.

**Security Sarah :** Ton site est en AMP. Le validateur va refuser la page.

**DevOps Dave :** Alors AMP est trop limité. C'est un défaut.

**Security Sarah :** Combien de domaines tiers ce script charge-t-il ?

**DevOps Dave :** Je ne sais pas. Quatre ? Cinq ?

**Security Sarah :** Ce que tu appelles un défaut, c'est la seule personne dans ton équipe qui dit non à ta place.

Dave n'a pas tort sur le fond : un site sans contrainte peut faire mieux qu'un site AMP. Mais un site sans contrainte fait rarement mieux en pratique, parce que chaque script ajouté « juste cette fois » finit par rester.

### Pour qui AMP a encore du sens en 2026

Si tu pars de zéro et que ta motivation est le référencement, AMP n'a plus d'argument : Google le traite comme n'importe quelle page, et une page HTML bien construite passe les Core Web Vitals sans moteur imposé. Si tu as besoin de JavaScript applicatif, AMP te gênera tous les jours. Si, en revanche, tu publies un site de contenu, que tu veux un seul gabarit pour tout, et que tu cherches un cadre qui t'empêche de dériver, la question se pose autrement. Le format ne t'apporte plus de faveurs. Il t'apporte une règle, un validateur et un budget, contre un moteur de 159 Ko et un rideau qui attend son ouverture.

Pour ce site, le thème reste en AMP. Les mesures de cet article rappellent au passage qu'une bonne part du poids d'une page AMP ne doit rien au format : ici, les polices et les images pèsent plus lourd que le moteur.

À ses débuts, AMP était un guichet réservé, avec une file plus courte et un badge à la boutonnière. Le guichet a fermé le 1er juillet. Ce qui reste, c'est le règlement intérieur, et on peut très bien continuer à le suivre sans que personne ne vous y oblige. C'est même la seule manière de vérifier si on le suivait pour le guichet ou pour le règlement.

---

[^1]: Le [billet de Google du 7 octobre 2015](https://blog.google/products-and-platforms/products/search/introducing-accelerated-mobile-pages/) présente « a new open source initiative called Accelerated Mobile Pages » et cite une trentaine d'éditeurs participants. Le nom du projet promettait l'accélération, le reste de l'histoire a surtout montré qui tenait l'accélérateur.

[^2]: Bing a annoncé son visualiseur et son cache AMP en septembre 2018, dans un billet de Fabrice Canel [repris sur le blog d'AMP le 19 septembre 2018](https://blog.amp.dev/2018/09/19/introducing-bing-amp-viewer-and-bing-amp-cache/), en demandant aux éditeurs d'autoriser le domaine `bing-amp.com` dans leurs règles CORS.

[^3]: L'[annonce de l'OpenJS Foundation du 10 octobre 2019](https://openjsf.org/blog/openjs-foundation-welcomes-amp-project-to-help-improve-user-experience-on-the-web) parle d'un format utilisé sur « more than 30 million domains ». Le projet changeait de gouvernance, la vitrine restait celle de Google.

[^4]: Le [billet de Google Search Central du 19 avril 2021](https://developers.google.com/search/blog/2021/04/more-details-page-experience) : « using the AMP format is no longer required and that any page, irrespective of its Core Web Vitals score or page experience status, will be eligible to appear in the Top Stories carousel ». Le même billet annonce la fin du badge AMP, avec un déploiement à partir de mi-juin 2021.

[^5]: Le [journal des modifications de Google Search Central](https://developers.google.com/search/updates) indique au 1er juillet 2026 : « Simplified our AMP documentation by removing outdated references to the AMP viewer, AMP Cache, and signed exchange ». La [page de Google sur AMP dans la recherche](https://developers.google.com/search/docs/crawling-indexing/amp) précise désormais que Google « applies the same standard to all pages, regardless of the technology used to build the page », et qu'après un clic depuis la recherche, l'adresse de la page AMP est visible dans le navigateur, comme pour toute page web.

[^6]: Les [versions publiées du dépôt `ampproject/amphtml`](https://github.com/ampproject/amphtml/releases) montrent une version stable le 18 août 2026 et une préversion le 26 août 2026, relevées le 4 octobre 2026.

[^7]: La [page d'AMP consacrée aux caches](https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/how_amp_pages_are_cached) affirme : « Currently, there are two AMP Cache providers: Google AMP Cache and Bing AMP Cache ». La page ne dit pas comment Bing s'en sert aujourd'hui.

[^8]: La [documentation d'AMP sur le style](https://amp.dev/documentation/guides-and-tutorials/develop/style_and_layout/) : « Each AMP page has a 75,000 byte CSS limit. Styles defined in the head of the document and inline count towards this limit. »

[^9]: La [page de référence des Core Web Vitals sur web.dev](https://web.dev/articles/vitals) fixe les seuils acceptables à 2,5 secondes pour le LCP, 200 millisecondes pour l'INP et 0,1 pour le CLS, mesurés au 75e centile des chargements, sur mobile comme sur ordinateur.

[^10]: La [spécification du code d'amorçage d'AMP](https://amp.dev/documentation/guides-and-tutorials/learn/spec/amp-boilerplate) décrit une animation CSS de huit secondes qui fait passer le corps de la page de `visibility:hidden` à `visible` : le moteur l'interrompt dès qu'il est prêt, et sans lui, la page s'affiche au bout de huit secondes. Le bloc `noscript` annule l'animation quand JavaScript est désactivé.

[^11]: La [documentation d'`amp-script`](https://amp.dev/documentation/components/amp-script) fixe 10 000 octets par script inline et 150 000 octets au total pour les scripts hors bac à sable, et limite les modifications du DOM dans les conteneurs de taille variable aux cinq secondes qui suivent un geste de l'utilisateur.

[^12]: La [page d'AMP sur les polices personnalisées](https://amp.dev/documentation/guides-and-tutorials/develop/style_and_layout/custom_fonts) le formule ainsi : « AMP pages can't include external stylesheets, with the exception of custom fonts ». Elle liste Google Fonts, Typekit, Fonts.com, Typography.com et Font Awesome, et laisse toute liberté aux polices déclarées par `@font-face` dans la feuille de style de la page.