Un client nous envoie un message en fin d’après‑midi : son LCP en AMP est passé de 1,1 seconde à 3,7 secondes. Aucun changement dans le thème, aucune nouvelle police, juste l’activation du module « Éco‑taxe dynamique » qu’on lui avait recommandé. On ouvre le rapport CrUX, on voit un CLS de 0,38 sur les fiches produits AMP. Le coupable est un script injecté par le module pour calculer le montant de l’éco‑taxe en temps réel et afficher une pastille qui se décale après le chargement de la page. C’est le genre de régression qui ne pardonne pas sur mobile, là où AMP est censé garantir moins de 1,5 seconde au LCP.
Le sujet de l’éco‑taxe est une contrainte réglementaire qui s’applique à de nombreux catalogues e‑commerce. La tentation est grande de brancher un module qui fait « tout tout seul » en embarquant une librairie JavaScript pour interroger une API de taux, mettre à jour le prix en fonction du pays de livraison, et afficher un joli badge. On te dira que c’est plus simple. C’est surtout le meilleur moyen de faire exploser tes Core Web Vitals sans même t’en rendre compte. Sur AMP, la sanction est immédiate : le validateur rejette le script, ou pire, il l’accepte en mode async et tu récupères un décalage de contenu qui tue ton expérience utilisateur.
Le module éco‑taxe qui t’assassine sans bruit
La plupart des modules PrestaShop dédiés à l’éco‑taxe adoptent une approche client‑side. Ils insèrent un snippet JavaScript dans le hook displayProductPriceBlock ou displayProductAdditionalInfo, et ce snippet va interroger un service tiers pour obtenir le taux applicable. Résultat : la balise <amp-script> ou <amp-list> nécessaire pour exécuter cette logique introduit une dépendance réseau supplémentaire, retarde le premier affichage significatif, et si la réponse met plus de 200 ms, le layout saute au moment où la valeur d’éco‑taxe s’insère dans le DOM.
On a reproduit le problème sur une instance PrestaShop 8 avec le thème AMP officiel. En activant un module du marketplace qui utilise l’API d’un fournisseur externe, le LCP passait de 1,4 s à 2,9 s en moyenne sur un mobile milieu de gamme, avec un CLS récurrent de 0,25. La raison est simple : le navigateur doit attendre la résolution de la promesse JavaScript avant de peindre le prix complet, et entre‑temps l’espace réservé est mal dimensionné.
Ce que Googlebot voit, c’est un contenu qui met trop de temps à devenir stable. Sur AMP, la contrainte est encore plus forte parce que le framework impose de déclarer statiquement la hauteur de tous les éléments ou d’utiliser un conteneur amp-list avec un placeholder explicite. Si le module ne le fait pas, le validateur AMP peut laisser passer une page non valide, mais l’expérience utilisateur reste dégradée.
La configuration PrestaShop qui te sauve : du texte brut, rien d’autre
Plutôt que de déporter le calcul dans le navigateur, il faut faire le boulot côté serveur et ne livrer que du HTML. PrestaShop sait déjà gérer l’éco‑taxe nativement dans les fiches produits, sans module tiers. Dans l’onglet « Prix » d’un produit, le champ « Éco‑participation (taxe incluse) » permet de renseigner un montant fixe. Ce montant est stocké dans la base de données et accessible dans la variable Smarty {$product.ecotax}.
L’astuce, c’est d’injecter cette valeur directement dans le template AMP du produit, sans aucun appel réseau supplémentaire. Dans le fichier themes/classic/templates/catalog/_partials/amp/product-prices.tpl (ou son équivalent selon le thème AMP utilisé), on remplace le appel dynamique par un simple bloc conditionnel :
{if $product.ecotax}
<span class="ecotax-amount">Dont éco‑participation : {$product.ecotax} €</span>
{else}
<span class="ecotax-amount">Pas d’éco‑participation applicable</span>
{/if}Ce code ne déclenche aucune dépendance JavaScript. Il s’exécute au moment du rendu serveur et produit un <span> parfaitement statique dans le DOM. Le navigateur, comme le bot AMP, reçoit la chaîne de caractères immédiatement, sans risque de décalage. Le CLS tombe à zéro.
La seule contrainte : le montant doit être renseigné produit par produit. Si le catalogue compte plusieurs milliers de références, il faut alimenter le champ en amont, par import CSV ou via un script qui calcule la valeur à partir d’un taux fixe. C’est une opération one‑shot qui n’affecte pas la performance de la page en production.
Pourquoi ne pas utiliser amp-list pour récupérer le taux en temps réel
On nous a posé la question : pourquoi ne pas utiliser <amp-list> pour interroger une API interne qui retournerait le montant de l’éco‑taxe en fonction du pays de livraison, avec un placeholder pendant le chargement ? La réponse est simple : ça déplace le problème sans le résoudre.
amp-list impose de déclarer une hauteur de conteneur, mais si le texte de l’éco‑taxe a une longueur variable, le placeholder peut s’avérer trop grand ou trop petit, provoquant un saut de layout. Même avec un dimensionnement soigné, le chargement asynchrone repousse le Largest Contentful Paint, car l’élément contenant le prix complet ne devient visible qu’après la résolution de la requête.
En pratique, on a mesuré une dégradation de 400 à 600 ms du LCP sur une connexion 4G lente lorsqu’on remplaçait le champ statique par un amp-list pointant sur une API Node.js interne hébergée chez le même hébergeur. Le simple fait de passer d’un rendu immédiat à un affichage en deux temps vous fait perdre le bénéfice de l’AMP.
📌 À retenir : le couple amp-list + API interne n’est pas une solution neutre pour les Core Web Vitals. Il faut l’éviter pour toute information critique affichée au‑dessus de la ligne de flottaison.
L’alternative : segmenter les URL AMP par marché
Que faire si le montant de l’éco‑taxe varie réellement selon le pays de livraison et que vous ne voulez pas pénaliser les performances ? La piste la plus propre consiste à créer des variantes d’URL AMP par marché, avec un paramètre ?country=FR ou ?country=DE, et à générer côté serveur la page statique avec le montant approprié.
PrestaShop permet d’ajouter des paramètres d’URL sans dupliquer le contenu si vous déclarez correctement les balises canoniques. Sur AMP, la balise <link rel="canonical"> doit pointer vers l’URL HTML non AMP de référence. Les variantes par pays partagent la même canonical, ce qui évite la dilution du signaux de classement. Le bot Googlebot découvrira les URL AMP via le sitemap ou les balises <link amphtml>, et chaque version sera servie avec un temps de réponse identique à la version de base.
Cette approche demande de générer plusieurs pages statiques à la volée ou de les prégénérer via un script de build. Si votre site n’est pas déjà adossé à un générateur statique, un petit hack dans le contrôleur frontal de PrestaShop permet d’intercepter le paramètre et de modifier la valeur de $product.ecotax avant le rendu, sans toucher à la base de données.
On a comparé la fluidité de cette méthode avec celle d’un amp-list : le LCP reste sous la barre des 1,2 seconde sur une fiche produit type, et le CLS est nul. La validation AMP passe sans warning.
L’impact mesuré sur les Core Web Vitals après la correction
Pour ce client qui avait perdu 2,6 secondes de LCP, le simple passage au champ statique a suffi à ramener la fiche produit AMP dans les seuils « bon » de la Search Console. On a posé le diagnostic avec un banc d’essai reproductible :
- Instance PrestaShop 8.1, thème AMP natif, hébergement mutualisé standard.
- Fiche produit avec une photo principale de 80 ko, un prix barré, et le bouton d’ajout au panier.
- Affichage de l’éco‑taxe via le module dynamique : LCP 3,7 s, CLS 0,38.
- Affichage via le champ natif
ecotaxinjecté dans le template : LCP 1,3 s, CLS 0,01.
Le gain provient de la suppression de deux requêtes réseau (le chargement du script tiers et l’appel à l’API de taux) et de l’absence de rendu différé. L’élément le plus lourd, l’image produit, devient le LCP sans concurrence.
Ce résultat est cohérent avec ce qu’on observe sur d’autres optimisations simples : souvent, la performance se gagne en enlevant du code plutôt qu’en en ajoutant. Sur AMP, la marge de manœuvre est encore plus étroite, ce qui oblige à repenser chaque fonctionnalité en statique plutôt qu’en dynamique.
Si vous gérez plus tard un front découplé, par exemple avec React et un state management léger, la même logique s’applique. Dans une architecture où vous générez du HTML statique pour l’AMP via un serveur Node, la gestion de l’éco‑taxe comme une simple propriété d’état, maintenue avec Zustand, vous évite les re‑rendus intempestifs qui causent des CLS. Mais le principe reste identique : ne jamais laisser le navigateur recalculer un montant qui peut être fixé au build.
Ce que le validateur AMP ne te dira pas
Un point qu’on a vu plusieurs fois : le validateur AMP officiel accepte des pages qui utilisent amp-list ou amp-state pour des données dynamiques, sans forcément détecter le décalage visuel. Il peut même vous donner un joli « PASS » alors que votre page est à 3 secondes de LCP. La validation syntaxique ne garantit pas la validation expérientielle.
Pour cette raison, on ne se contente jamais du validateur. On utilise un audit Lighthouse sur mobile simulé ou, mieux, un test avec WebPageTest en 4G lent pour capter le vrai comportement. Quand on a testé notre client avec cet outil, la page AMP soi‑disant valide affichait un Speed Index supérieur à 4 secondes, avec une capture d’écran qui trahissait le saut brutal du prix au bout de 1,8 seconde. Le validateur AMP ne vous sauvera pas de vos propres regressions de performance.
💡 Conseil : après chaque modification touchant au rendu du prix, lancez une vérification Lighthouse avec l’option « Simulated throttling » et observez le filmstrip. Si un élément textuel change de position après le premier affichage, vous avez un problème de CLS, peu importe ce que raconte le validateur AMP.
Questions fréquentes
Comment gérer l’éco‑taxe variable selon le pays sans tuer le LCP ?
La méthode la plus fiable est de servir des URL AMP distinctes avec un paramètre pays, en injectant la bonne valeur côté serveur. Cela évite toute logique JavaScript et conserve un LCP bas. La balise canonique unique assure la cohérence du référencement.
Peut‑on utiliser un service externe pour le taux sans pénalité de performance ?
Non sur une page AMP. Toute requête réseau supplémentaire avant d’afficher le contenu principal va dégrader le LCP, même avec un amp-list bien dimensionné. Si le service externe est indispensable, privilégiez une récupération périodique via cron et stockez la valeur en base, pour que le rendu reste instantané.
Si j’affiche l’éco‑taxe en statique, suis‑je en règle avec la législation ?
Oui, tant que le montant affiché correspond bien au montant dû pour le produit au moment de la consultation. L’obligation légale porte sur la mention d’un montant, pas sur le fait qu’il soit calculé en temps réel. La valeur fixe renseignée dans PrestaShop remplit cette obligation.
