Black Friday 2025. Un site d’électroménager qu’on suivait affiche un LCP à 1,8 seconde sur mobile, un score Lighthouse à 98. Ses pages produits sont en AMP depuis trois ans. Taux de conversion mobile ce jour-là : en baisse de 12 % par rapport à un samedi normal. Le problème n’était pas la vitesse de chargement. C’était la réactivité. L’INP avait grimpé à 480 ms sur le fil d’interaction principal, pile au moment où les serveurs commençaient à saturer.
On te dira que l’AMP accélère tout et qu’un site propulsé par le cache Google est imbattable pour les pics de trafic. C’est une demi-vérité qui a fait son temps. En 2026, planifier son e-commerce pour les fêtes en misant sur l’AMP, c’est confondre un format de page avec une stratégie de performance. La vraie menace pour la conversion, c’est l’Interaction to Next Paint. Et l’AMP, par conception, ne fait rien pour le contenir.
Le mirage AMP des pics de trafic
L’AMP est né en 2015 avec une promesse : des pages mobiles ultra-rapides, servies depuis un cache Google, et une exposition prioritaire dans les résultats d’actualité. Pendant quelques années, convertir son catalogue en AMP relevait d’une tactique défendable pour gagner en visibilité sur mobile. Mais depuis la page experience update de 2021, Google a retiré le badge AMP des SERP et ne l’exige plus pour les Top Stories. Le signal de classement a disparu. Ce qu’il reste, c’est un format restrictif qui impose un sous-ensemble de HTML, des composants JavaScript verrouillés et une dépendance à un cache tiers.
Sous un pic de trafic saisonnier, l’enjeu n’est pas la vitesse de chargement initial. Les pages AMP affichent souvent un LCP flatteur en laboratoire parce qu’elles limitent les ressources bloquantes. Mais dès que tu branches un script de personnalisation, un chatbot ou un pixel de retargeting, le thread principal se retrouve saturé exactement comme sur une page canonique. La seule différence, c’est que tu as moins de contrôle sur l’exécution des scripts parce que l’AMP sandboxe ce qu’il autorise à s’exécuter. Résultat : un LCP qui reste dans le vert et un INP qui explose sans que le tableau de bord AMP ne te prévienne.
Ce que les Core Web Vitals mesurent vraiment pendant les fêtes
Le piège classique, c’est de réduire les Core Web Vitals à un seul chiffre : le LCP. Or, les données de terrain collectées pendant les périodes de fort trafic montrent une dégradation bien plus marquée sur l’INP que sur le LCP. La raison est simple : un CDN bien configuré absorbe les pics de requêtes pour les ressources statiques, ce qui protège le Largest Contentful Paint. Mais le JavaScript qui s’exécute côté client, celui qui gère les filtres de navigation, l’ajout au panier ou la validation de formulaire, dépend de la capacité du navigateur à traiter de longues tâches. Quand le CPU du mobile est déjà entamé par dix scripts tiers, la file d’attente de l’event loop s’allonge et l’INP passe au rouge.
Le pire, c’est que l’AMP masque ce phénomène. Les outils de monitoring AMP te renvoient un score de performance centré sur le FCP et le LCP, deux métriques qui ne capturent pas l’interactivité. Ce n’est qu’en croisant les données du rapport Core Web Vitals de la Search Console avec un RUM outil que l’on découvre l’étendue des dégâts. Une page AMP peut parfaitement valider tous les critères de la version 2 du framework tout en affichant un INP à 400 ms sur le terrain, loin du seuil des 200 ms. Si vous voulez comprendre comment les Core Web Vitals capturent l’expérience réelle, il faut sortir du paradigme AMP et raisonner en optimisation des signaux mesurables.
INP à 350 ms : le tueur silencieux des conversions de Noël
L’Interaction to Next Paint mesure le temps entre une action utilisateur (un clic, un toucher) et le prochain affichage visuel. Sous 200 ms, l’expérience est fluide. Au-delà de 500 ms, la sensation de lourdeur est immédiate. Et ce délai, pendant les fêtes, il n’est pas causé par un code métier mal écrit. Il est provoqué par l’accumulation de long tasks générées par les scripts tiers que l’on ajoute au dernier moment : une bannière d’offre, une pop-up de livraison offerte, un test A/B, un widget de financement. Chacun de ces scripts pèse sa micro-exécution, et leur somme forme une barrière d’interactivité.
Sur une architecture AMP, tu n’as pas la main pour casser ces longues tâches. Tu ne peux pas découper tes bundles, tu ne peux pas implémenter de scheduler asynchrone fin, tu ne peux pas différer l’hydratation partielle d’un composant lourd. Les seuls leviers disponibles sont de supprimer des fonctionnalités, ce qui revient à amputer l’expérience utilisateur. Sur une stack moderne, tu peux agir. Par exemple, dans une application React qui gère une fiche produit dynamique, une gestion fine des états avec Zustand limite les re-rendus inutiles et préserve le thread principal. Résultat : l’INP descend sous les 200 ms même quand les widgets marketing sont chargés. C’est ce genre de micro-optimisation qui fait la différence le jour où le trafic triple, pas le fait d’avoir remplacé <img> par <amp-img>.
⚠️ Attention : Un INP dégradé ne déclenche aucune alerte dans les outils AMP. Ne vous fiez pas au score Lighthouse d’une page AMP pour valider sa réactivité sous charge réelle.
Cache HTTP, CDN, purges ciblées : le vrai planning technique
Quand on prépare un site e-commerce pour les fêtes, la première brique de performance n’est pas le format des pages. C’est la stratégie de cache. Beaucoup d’équipes installent un plugin de cache côté serveur, règlent un TTL de 24 heures sur les pages produits et considèrent que le travail est fait. Le problème, c’est que pendant les opérations commerciales, les prix, les stocks et les bannières promotionnelles changent plusieurs fois par jour. Une purge complète du cache pour mettre à jour un badge « -20 % » casse le ratio de hit et renvoie tous les utilisateurs vers l’origine, créant un goulet d’étranglement au pire moment.
L’alternative, c’est un cache stale-while-revalidate en périphérie, avec purge sélective par tag. Une page catégorie reçoit un tag « promo-noel ». Quand la bannière change, on purge uniquement les objets marqués de ce tag, sans toucher au cache des fiches produits. Pendant ce temps, le CDN continue de servir une version périmée de quelques secondes à ceux qui arrivent, tandis qu’il regénère la version fraîche en arrière-plan. Cette approche ne demande pas de réécrire ses pages en AMP. Elle demande de configurer les en-têtes HTTP correctement et d’avoir un reverse proxy qui comprend les tags. Les gains sur l’INP sont indirects mais massifs : en réduisant le temps d’attente sur la première réponse serveur, on libère du CPU client pour les interactions ultérieures.
Et le SEO dans tout ça ?
Le seul bénéfice SEO qu’offrait l’AMP, c’était le carrousel de résultats enrichis réservé aux pages AMP dans Google Actualités. Google a officiellement cessé d’en faire un prérequis il y a plusieurs années. Aujourd’hui, les signaux de classement s’appliquent uniformément à toutes les pages mobiles. Si votre URL AMP est indexée à côté de votre URL canonique, vous divisez vos signaux de crawl et diluez votre maillage interne. La recommandation technique n’a pas bougé : consolider sur une seule version, avec des redirections 301 propres, bien avant novembre.
Pendant qu’on nettoie la dette technique, on peut aussi s’attaquer à la taille des bundles JavaScript qui plombent le LCP et l’INP. Une refonte du code legacy avec Claude Code plutôt qu’un IDE classique permet d’automatiser le dédoublonnage de dépendances et l’élimination de modules morts. On a vu des lots passer de 240 ko à 90 ko en une matinée, essentiellement parce que l’outil identifie des arbres d’imports jamais exécutés que le tree-shaking standard ne détecte pas. Moins de JavaScript à parser, c’est moins de long tasks pour le navigateur. Et ça, aucun cache AMP ne le fait à votre place.
Auditer son site e-commerce 4 mois avant les fêtes
Un audit de performance ne commence pas par un rapport Lighthouse. Il commence par les logs serveur. Les logs donnent la distribution réelle des temps de réponse, le taux de requêtes vers l’origine, et les routes les plus lentes. Une fois les points noirs identifiés, on peut calibrer un plan d’action en trois étapes : réduction des long tasks, optimisation des chaînes de dépendances critiques, dimensionnement du cache.
La réduction des long tasks passe par un audit JavaScript avec l’onglet Performance des DevTools en simulant un CPU mobile ralenti. On identifie les fonctions qui monopolisent le thread plus de 50 ms, on les fractionne ou on les déplace dans un web worker quand c’est possible. L’optimisation des dépendances critiques, c’est la priorité de chargement : fetchpriority="high" sur l’image LCP, preload sur les fonts, async sur les scripts tiers non essentiels. Enfin, le dimensionnement du cache doit être testé avec des outils de montée en charge (k6, Gatling) pour valider que l’origine tient le trafic attendu multiplié par trois, même si le CDN absorbe 95 % des requêtes.
Cette checklist demande quatre mois parce que chaque modification touche des régressions potentielles sur le parcours d’achat. La dernière ligne droite, c’est un gel des déploiements non essentiels trois semaines avant le Black Friday, et une surveillance de l’INP via le rapport Core Web Vitals de la Search Console, pas via les scores de laboratoire.
Questions fréquentes
Faut-il supprimer ses pages AMP existantes avant les fêtes ? Pas forcément, surtout si votre trafic mobile y est habitué. Mais n’investissez pas dans de nouvelles pages AMP. Mettez plutôt en place des redirections 301 progressives vers les canons, en surveillant la couverture d’indexation dans la Search Console. L’objectif est d’avoir consolidé avant le pic de décembre.
L’AMP est-il encore utile pour les carrousels Google Actualités ? Non. Google n’impose plus l’AMP pour apparaître dans les carrousels Top Stories. N’importe quelle page correctement indexable, rapide et au balisage article structuré peut y figurer. La condition ne porte plus sur le format mais sur la performance et la pertinence.
Comment mesurer l’INP sur un site e-commerce sans outil payant ? Activez l’extension Web Vitals en navigation privée et effectuez un parcours d’achat complet. Les résultats remontent dans l’onglet Core Web Vitals de la Search Console une fois que le volume de données terrain est suffisant. Pour un diagnostic plus fin, le rapport « Performances » de Chrome DevTools en simulation 4x CPU ralentit le thread principal et fait ressortir les longues tâches coupables.
