Core Web Vitals sur une page produit : LCP (plus grand élément visible, souvent l'image), INP (réactivité : variantes, ajouter au panier), CLS (décalages : prix, bandeaux, avis). Google les utilise. Les humains aussi, sans les nommer : « la page rame, je suis parti ». Cet article se concentre sur la page produit, pas sur la home. WooCommerce, PrestaShop, autre : les motifs sont les mêmes. Galeries, variantes, avis, recommandations, pixels. On mesure, on coupe, on remesure.
🔎 Pourquoi la page produit, pas seulement la home
La home est un plateau. La page produit est le rayon. Le SEO marchand et les ads atterrissent ici. Un LCP de home à 1,8 s et un LCP de page produit à 6 s, c'est une boutique qui « a de bonnes perfs » dans le reporting et de mauvaises ventes dans la vraie vie. On mesure l'URL qui compte.
Search Console segmente. CrUX aussi. On les lit. On ne se félicite pas d'une home en cache anonyme.
🛠️ LCP : presque toujours l'image produit
Le plus grand élément est l'image principale. Elle doit être priorisée (preload si besoin), dimensionnée, dans un format moderne, pas un carrousel JS qui décide tard. Les galeries qui chargent huit images en taille réelle tuent le LCP. Une image nette, les autres en lazy.
Le hero de marque au-dessus, le bandeau promo, le slider de « looks » : ils volent parfois le titre de LCP. On les réduit. Le LCP doit être le produit, pas le marketing autour.
✅ INP : variantes, zoom, ajouter au panier
Cliquer une taille, un coloris, le bouton panier : si le thread JS est occupé par un avis, un chat, un pixel, l'INP grimpe. On reporte les scripts non essentiels. On évite les libs lourdes pour un zoom. On teste sur mobile milieu de gamme, pas sur un Mac.
Les plugins de personnalisation (gravure, preview) se chargent à la demande, pas pour tous les produits. L'INP d'une page produit simple ne doit pas payer la page produit complexe.
⚠️ CLS : prix, stocks, bandeaux, polices
Le prix qui s'injecte, le bandeau cookie, la barre promo, les webfonts qui s'affichent tard, les avis qui poussent le bouton : le layout saute, le doigt se trompe. On réserve les hauteurs, on pose les fonts, on n'insère pas de bandeau après le premier affichage.
Les A/B et les popins « -10 % » sont des ennemis du CLS. Si le métier les veut, on les réserve. On ne les parachute pas.
- Image principale : prioritaire, une seule full, le reste lazy
- JS des avis / reco / chat en différé
- Slots réservés pour prix, promo, cookie
- Mesure mobile sur la vraie page produit, pas la home
📌 WooCommerce et PrestaShop : motifs fréquents
Woo : thèmes builders sur la page produit, plugins de galerie, variations AJAX trop riches, produits liés trop gourmands en requêtes. Presta : modules de zoom, packs, cross-sell, thèmes marketplace qui chargent tout le JS produit. Dans les deux cas, on désactive module par module sur une copie de test en mesurant.
Le cache de page : une page produit avec mini-panier dynamique se cache mal. On cache l'anonyme, on ESI / on fragmente si l'infra sait. Mal cacher une page produit, c'est servir le mauvais prix. Ne pas cacher, c'est un TTFB triste. On choisit, on documente.
🧭 Mesurer : lab et field
Lab (Lighthouse, WebPageTest) pour itérer. Field (CrUX, RUM) pour la vérité. Une page produit qui passe en lab et échoue en field a un JS tiers (ads, tags) que le lab a bloqué. L'audit campagne doit inclure les tags réels.
On fixe un budget : LCP < 2,5 s sur un 4G médian pour les top SKU. On ne promet pas ça sur une page produit à 20 vidéos. On change alors le contenu, pas seulement le serveur.
💡 Lien avec l'hébergement et l'allègement
Un TTFB de page produit à 2 s, on va vers PHP, cache, base (articles héberger et alléger). Un LCP image, on va vers les médias. Un INP, vers les plugins. Core Web Vitals sur une page produit est un diagnostic, pas un plugin « CWV optimizer ».
Je le fais dans les audits Woo / Presta et dans la TMA avant les pics. La page produit est le produit. Elle mérite le même soin que le tunnel de vente. Parfois plus : c'est elle que Google montre.
🧪 Contenu de la page produit : le levier qu'on évite
20 onglets, une vidéo autoplay, des avis iframe, un configurateur 3D pour une chaussette : aucun hébergeur ne rattrape ça. Core Web Vitals sur une page produit, c'est aussi un brief contenu. On peut tout avoir, pas tout au-dessus de la ligne de flottaison, pas tout en JS bloquant.
Les équipes produit détestent cette phrase. Les équipes ads l'aiment : leur landing tient. Je tranche. L'article existe pour donner un vocabulaire commun (LCP, INP, CLS) à cette décision.
🔎 Top SKU d'abord
On ne soigne pas 8 000 pages produits d'un coup. On prend le top trafic / top chiffre d'affaires, on pose le modèle (image, JS, slots), on étend. Un thème corrigé bénéficie à toutes. Un plugin de galerie retiré aussi. Le contenu aberrant se traite SKU par SKU.
C'est de la TMA e-commerce, pas un projet « CWV » de six mois. Une page produit pilote, une semaine, une généralisation. Puis on surveille Search Console. Les Core Web Vitals d'une page produit se jugent au field, trois semaines plus tard, pas au Lighthouse du vendredi.
Un Lighthouse vert sur la home ne dit rien de la page produit qui encaisse.
