Core Web Vitals PrestaShop : le protocole pour atteindre 90+ sur Google PageSpeed

\n\n

Votre boutique PrestaShop affiche un score PageSpeed mobile sous la barre des 70, et vous savez que Google en tient compte dans son classement depuis 2021. Après 193 projets PrestaShop livrés, j'ai constaté que 80 % des boutiques que j'audite souffrent des mêmes pathologies sur les Core Web Vitals — et que la plupart se corrigent avec un protocole méthodique plutôt qu'une liste de plugins miracles. Sur mon propre Hub Pro (alexandrecarette.fr), je suis passé d'un score mobile de 55 à 91 après migration headless et optimisation nginx. Dans cet article, je vous livre le diagnostic complet, les corrections par ordre de priorité, et les résultats mesurables que vous pouvez attendre.

\n\n

Nous allons couvrir les trois métriques qui comptent en 2026 — LCP, CLS et INP —, identifier les cinq problèmes structurels des thèmes PrestaShop classiques, puis dérouler un protocole en trois phases que vous pouvez appliquer dès aujourd'hui sur votre boutique.

\n\n

Les 3 Core Web Vitals en 2026 : ce qui a changé pour PrestaShop

\n\n\n\n

Depuis mars 2024, Google a remplacé le First Input Delay (FID) par l'Interaction to Next Paint (INP). Ce changement est majeur pour l'écosystème PrestaShop : là où le FID mesurait uniquement le délai de la première interaction, l'INP évalue la réactivité de toutes les interactions utilisateur pendant la session. Concrètement, un module jQuery qui bloque le thread principal pendant 400 ms à chaque clic « Ajouter au panier » passait inaperçu avec le FID — il est désormais sanctionné par l'INP.

\n\n

Les seuils à retenir :

LCP (Largest Contentful Paint) : inférieur à 2,5 secondes — c'est le temps d'affichage de l'élément le plus volumineux visible (souvent le slider ou l'image produit principale).
CLS (Cumulative Layout Shift) : inférieur à 0,1 — mesure la stabilité visuelle de la page pendant le chargement.
INP (Interaction to Next Paint) : inférieur à 200 ms — la réactivité perçue à chaque interaction (clic, tap, saisie clavier).

\n\n

Selon Google Search Central, ces métriques constituent un facteur de classement officiel. Ce n'est plus un signal secondaire : un site qui échoue sur les CWV est objectivement désavantagé dans les résultats de recherche face à un concurrent qui les passe.

\n\n

Les problématiques CWV typiques d'un PrestaShop non optimisé

\n\n\n\n\n\n\n\n\n\n\n\n\n

Problématique	Cause principale	Impact métier
LCP supérieur à 4 secondes sur mobile	Slider homepage avec images PNG/JPG non compressées servies sans CDN, souvent en 1920×800 px sans srcset responsive	53 % des visiteurs mobiles abandonnent après 3 secondes de chargement (source : Google). Perte directe de trafic et de CA.
CLS supérieur à 0,25 au chargement	Calcul asynchrone des prix TTC/HT via JavaScript — le bloc prix se redimensionne après le rendu initial, décalant tout le contenu en dessous	Expérience dégradée : l'utilisateur clique sur le mauvais élément, taux de rebond en hausse, perte de confiance.
INP supérieur à 500 ms sur les fiches produit	Listeners jQuery hérités des modules tiers (comparateur de prix, pop-ups newsletter, sliders de produits associés) qui bloquent le thread principal	L'ajout au panier semble « gelé » pendant une demi-seconde — le client doute et quitte. INP « Poor » sur le rapport CrUX.
CSS et JS render-blocking	Les thèmes classiques PrestaShop chargent 15 à 30 fichiers CSS/JS en synchrone dans le <head>, incluant des librairies rarement utilisées (Font Awesome complet, jQuery UI, Fancybox)	Le First Contentful Paint est retardé de 2 à 4 secondes. Google PageSpeed signale systématiquement « Eliminate render-blocking resources ».
Images non optimisées (absence de WebP et lazy-load défaillant)	Le CMS sert les images uploadées en format original (JPG/PNG) sans conversion WebP côté serveur. Le lazy-loading natif est mal implémenté ou absent sur les images above-the-fold.	Poids de page moyen supérieur à 4 Mo sur les catégories produit. Le LCP explose sur les connexions 4G dégradées, typiques du m-commerce.

\n\n

Protocole d'optimisation en 3 phases

\n\n

Voici le protocole exact que j'applique sur les projets clients et que j'ai utilisé pour le Hub Pro alexandrecarette.fr. Il est structuré pour produire des résultats mesurables à chaque étape.

\n\n

Phase 1 : Audit — mesurer avant d'agir

\n\n

Google Search Console → rapport Core Web Vitals : identifiez les URLs en statut « Poor » et « Needs Improvement ». Priorisez par volume de trafic.
PageSpeed Insights : lancez un test sur vos 5 templates critiques (accueil, catégorie, fiche produit, panier, checkout). Notez le LCP, CLS et INP pour chacun.
CrUX Dashboard (Chrome UX Report) : vérifiez les données terrain sur 28 jours. Les données lab (Lighthouse) et les données terrain (CrUX) divergent souvent — c'est le terrain qui compte pour Google.
Chrome DevTools → onglet Performance : enregistrez une session de navigation réelle sur mobile throttled (4G lente). Identifiez les Long Tasks JavaScript qui bloquent le thread principal au-delà de 50 ms.

\n\n

Dans un projet récent pour un client dans le secteur de la mode (catalogue de 3 500 références sur PrestaShop 1.7), l'audit a révélé que 72 % du temps de blocage JS provenait d'un seul module tiers de filtres à facettes. Le supprimer et le remplacer par une solution native a fait passer l'INP de 620 ms à 180 ms — sous le seuil « Good » — sans aucune autre modification.

\n\n

Phase 2 : Quick wins — gains immédiats sans refonte

\n\n

Compression Brotli/Gzip sur nginx : activez brotli on; et brotli_types text/html text/css application/javascript application/json image/svg+xml;. Gain typique : 20 à 30 % de réduction du poids transféré.
Cache navigateur agressif : configurez des headers Cache-Control: public, max-age=31536000, immutable sur les assets statiques (CSS, JS, images, fonts). Sur PrestaShop, activez le CCC (Combine, Compress & Cache) dans Paramètres avancés → Performances.
Preconnect CDN et polices : ajoutez <link rel="preconnect" href="https://fonts.google.com" crossorigin> et équivalent pour votre CDN dans le <head>. Cela réduit le LCP de 100 à 300 ms en éliminant le temps de résolution DNS et de négociation TLS.
Conversion WebP des images : utilisez cwebp ou un module PrestaShop dédié pour servir automatiquement les images en WebP. Réduction moyenne de 25 à 35 % par rapport au JPEG, à qualité visuelle équivalente.
Dimensions explicites sur les images et iframes : attribuez width et height à chaque balise <img> pour éliminer les décalages CLS. Réservez l'espace du bloc prix côté CSS avec une hauteur minimale.

\n\n

Selon l'étude Google/Deloitte de 2020, régulièrement citée par web.dev, chaque amélioration de 0,1 seconde du LCP augmente le taux de conversion d'environ 8 % sur mobile. Sur un site e-commerce à 50 000 € de CA mensuel, c'est 4 000 € de revenu supplémentaire par mois pour quelques heures de configuration serveur.

\n\n

Phase 3 : Optimisations structurelles — l'avantage headless

\n\n

Les quick wins permettent généralement de passer de 45-55 à 65-75 sur mobile. Pour franchir la barre des 90, il faut adresser les problèmes structurels — et c'est là que l'architecture headless PrestaShop + Nuxt 3 offre un avantage décisif.

\n\n

Avec un frontend Nuxt 3 en SSR (Server-Side Rendering), le HTML est pré-rendu côté serveur et envoyé complet au navigateur. Le LCP ne dépend plus du temps d'exécution JavaScript client — il dépend du temps de réponse serveur (TTFB) et du poids de la page. C'est exactement ce que j'ai implémenté sur le Hub Pro, et les résultats parlent d'eux-mêmes : 91 sur mobile, 98 sur desktop après la migration headless.

\n\n

Voici la configuration nginx qui a fait la différence sur les pages blog — le LCP était systématiquement dégradé par l'image de couverture des articles :

\n\n

Servir les images statiques directement via nginx : le répertoire /blog-covers/ est configuré comme un alias statique nginx avec cache longue durée. L'image ne passe jamais par le runtime Node.js/Nuxt — elle est servie directement par nginx avec les headers de cache appropriés. Résultat : le LCP sur les pages articles est passé de 3,2 s à 1,1 s sur mobile.
Critical CSS inline : Nuxt 3 extrait automatiquement le CSS critique et l'inline dans le <head>. Le reste est chargé en async. Aucun CSS render-blocking.
Hydratation sélective : les composants purement visuels (sections témoignages, footer, FAQ) ne sont pas hydratés côté client — ils restent en HTML statique. Moins de JS = INP structurellement meilleur.

\n\n

Pour comprendre en détail comment cette architecture headless se met en place, j'ai documenté le processus complet dans mon article Hub Pro headless : Nuxt 3, Docker et PrestaShop découplé. Et si vous voulez automatiser les tests de performance dans votre pipeline, l'article sur le CI/CD avec GitHub Actions pour PrestaShop headless explique comment intégrer Lighthouse CI pour bloquer un déploiement si le score PageSpeed régresse.

\n\n

Comparatif avant/après : résultats mesurables

\n\n\n\n\n\n\n\n\n\n\n\n\n

Solution appliquée	Complexité	Gain estimé sur le score PageSpeed
Activation CCC PrestaShop + compression Gzip nginx	Faible	+5 à +10 points (réduction du poids CSS/JS de 25 %)
Conversion WebP systématique + lazy-load natif corrigé	Faible	+8 à +15 points (LCP amélioré de 0,5 à 1,5 s)
Suppression des modules JS tiers non essentiels + defer des scripts restants	Moyenne	+10 à +20 points (INP divisé par 2 à 3)
Compression Brotli + preconnect CDN + cache navigateur immutable	Faible	+5 à +8 points (TTFB et transfert réduits)
Migration headless Nuxt 3 SSR + images servies en statique nginx	Élevée	+25 à +40 points (refonte structurelle : SSR, critical CSS inline, zéro render-blocking)

\n\n

Sur le Hub Pro alexandrecarette.fr, le cumul de ces optimisations a produit les résultats suivants :

Score mobile : 55-62 → 91
Score desktop : 72 → 98
LCP mobile : 4,1 s → 1,1 s
CLS : 0,28 → 0,02
INP : 380 ms → 95 ms

\n\n

\n
"Good page experience involves more than Core Web Vitals. Good stats in the Core Web Vitals report in Search Console or third-party CWV reports don't guarantee good rankings. [...] However, having good Core Web Vitals can give your site a ranking advantage over sites with poor Core Web Vitals, all other things being equal."
\n— Google Search Central, Core Web Vitals & Page Experience (2024)\n

\n\n

Conclusion : la performance n'est pas un luxe, c'est un levier de conversion

\n\n

Les Core Web Vitals ne sont pas un exercice académique. Ce sont des métriques directement corrélées à vos revenus : chaque 0,1 seconde gagnée sur le LCP représente environ 8 % de conversions supplémentaires sur mobile. Avec 53 % des visiteurs mobiles qui abandonnent au-delà de 3 secondes, un PrestaShop non optimisé laisse littéralement de l'argent sur la table. Le protocole en trois phases — audit terrain, quick wins serveur, puis optimisations structurelles — permet de passer progressivement d'un score de 50-60 à 90+ sans tout casser du jour au lendemain. Et si votre ambition est de franchir durablement cette barre, l'architecture headless PrestaShop + Nuxt 3 offre un avantage structurel que les thèmes monolithiques ne pourront jamais égaler.

\n\n

Vous souhaitez savoir où se situent les Core Web Vitals de votre boutique PrestaShop et quels leviers prioriser ? Je propose un audit CWV personnalisé : analyse de vos 5 pages critiques, identification des 3 corrections à plus fort impact, et estimation du gain en score et en taux de conversion. Contactez-moi : contact@alexandrecarette.fr

\n\n

Sources et références

Approfondir dans l'Academy

Module : SEO Technique pour PrestaShop →

\n\n \n\n

Articles dans le même univers

Questions fréquentes

Qu'est-ce que les Core Web Vitals et pourquoi sont-ils importants pour PrestaShop ?: Les Core Web Vitals sont trois métriques de performance web définies par Google : LCP (vitesse d'affichage), CLS (stabilité visuelle) et INP (réactivité aux interactions). Depuis 2021, ils constituent un facteur de classement officiel dans les résultats de recherche. Pour une boutique PrestaShop, de mauvais CWV signifient un désavantage SEO direct face aux concurrents mieux optimisés.
Quel est le score PageSpeed moyen d'une boutique PrestaShop non optimisée ?: En moyenne, une boutique PrestaShop avec un thème classique non optimisé obtient entre 25 et 55 sur mobile dans PageSpeed Insights. Les principales causes sont les fichiers CSS/JS render-blocking, les images non compressées et les modules jQuery lourds. Sur desktop, le score est généralement 15 à 25 points plus élevé grâce à la puissance de calcul supérieure.
Quelle est la différence entre FID et INP pour PrestaShop ?: Le FID (First Input Delay) mesurait uniquement le délai de la première interaction utilisateur. L'INP (Interaction to Next Paint), qui l'a remplacé en mars 2024, mesure la réactivité de toutes les interactions pendant la session. C'est pénalisant pour PrestaShop car les modules tiers jQuery créent des blocages récurrents du thread principal à chaque clic, pas seulement au premier.
Comment mesurer les Core Web Vitals de ma boutique PrestaShop ?: Utilisez trois outils complémentaires : PageSpeed Insights pour un diagnostic rapide, le rapport Core Web Vitals de Google Search Console pour les données terrain sur 28 jours, et Chrome DevTools (onglet Performance) pour identifier précisément les scripts qui bloquent le rendu. Les données CrUX (terrain) comptent plus que les données lab pour le ranking Google.
Le CCC (Combine Compress Cache) de PrestaShop suffit-il pour atteindre un bon score ?: Le CCC améliore le score de 5 à 10 points en combinant et minifiant les fichiers CSS/JS. C'est un quick win nécessaire, mais insuffisant seul. Il ne résout pas les problèmes structurels comme les images non WebP, les modules JS tiers bloquants ou l'absence de critical CSS inline. C'est une première étape, pas une solution complète.
Comment optimiser le LCP sur une fiche produit PrestaShop ?: Le LCP sur une fiche produit est généralement l'image principale. Convertissez-la en WebP, servez-la en taille adaptée via srcset, ajoutez un preload dans le head pour cette image spécifique, et assurez-vous qu'elle n'est PAS en lazy-load (elle est above-the-fold). Côté serveur, activez Brotli et configurez un cache longue durée sur les images.
Comment réduire le CLS causé par le calcul des prix TTC/HT sur PrestaShop ?: Le décalage vient du fait que le prix est recalculé côté JavaScript après le rendu initial. Deux solutions : réservez l'espace du bloc prix avec une hauteur minimale CSS fixe (min-height), ou mieux, calculez le prix TTC côté serveur pour l'inclure directement dans le HTML initial. Sur un thème headless Nuxt SSR, le prix est rendu côté serveur, éliminant le problème à la racine.
Quels modules PrestaShop dégradent le plus les Core Web Vitals ?: Les modules les plus problématiques sont généralement : les sliders d'images homepage (Nivo Slider, Revolution Slider), les modules de filtres à facettes non optimisés, les pop-ups newsletter avec jQuery UI, les modules de chat en direct avec scripts externes, et les modules de réseaux sociaux chargeant des iframes. Auditez chaque module avec Chrome DevTools pour mesurer son impact réel.
Est-il possible d'atteindre 90+ sur mobile sans passer en headless ?: C'est possible mais difficile. Il faut un thème léger sur mesure, supprimer tous les modules JS non essentiels, activer Brotli, convertir toutes les images en WebP, inliner le critical CSS manuellement et defer tous les scripts. Comptez un score réaliste de 75-85 sur mobile avec un PrestaShop monolithique très optimisé. Le headless débloque les 90+ grâce au SSR natif et à l'absence de jQuery.
Quel est l'impact réel des Core Web Vitals sur le taux de conversion ?: Selon l'étude Google/Deloitte de 2020, chaque amélioration de 0,1 seconde du LCP augmente le taux de conversion d'environ 8 % sur mobile. Par ailleurs, 53 % des visiteurs mobiles abandonnent une page qui met plus de 3 secondes à charger. Sur un site e-commerce à 50 000 € de CA mensuel, optimiser le LCP de 1 seconde peut représenter 4 000 à 8 000 € de revenus supplémentaires mensuels.
Comment configurer nginx pour améliorer les Core Web Vitals de PrestaShop ?: Les configurations clés sont : activer Brotli (brotli on; brotli_types text/html text/css application/javascript), configurer le cache navigateur avec Cache-Control immutable sur les assets statiques, servir les images volumineuses directement depuis nginx en alias statique (sans passer par PHP ou Node), et activer HTTP/2 pour le multiplexage des requêtes. Ces seules modifications peuvent gagner 10 à 15 points PageSpeed.
Quelle est la différence entre les données lab et les données terrain (field) pour les CWV ?: Les données lab proviennent de tests simulés (Lighthouse, PageSpeed Insights mode lab) dans des conditions contrôlées. Les données terrain (field/CrUX) proviennent des vrais utilisateurs Chrome sur 28 jours. Google utilise les données terrain pour le ranking. Un site peut avoir un excellent score lab mais échouer en terrain si ses utilisateurs réels ont des connexions lentes ou des appareils peu puissants.
Comment Nuxt 3 améliore structurellement les Core Web Vitals par rapport à un thème PrestaShop classique ?: Nuxt 3 en SSR pré-rend le HTML côté serveur, éliminant le render-blocking JS. Le critical CSS est automatiquement inliné. L'hydratation sélective permet de ne charger le JavaScript que pour les composants interactifs. Il n'y a pas de jQuery ni de dépendances héritées. Le résultat est un TTI (Time to Interactive) et un INP structurellement inférieurs, et un LCP qui ne dépend que du TTFB et du poids de la page.
Combien de temps faut-il pour que les améliorations CWV impactent le ranking Google ?: Google utilise les données CrUX sur une fenêtre de 28 jours. Après vos optimisations, il faut donc au minimum 28 jours pour que les nouvelles métriques terrain se stabilisent, puis un délai supplémentaire variable pour que l'impact sur le classement se manifeste. En pratique, comptez 1 à 3 mois pour observer un effet mesurable sur vos positions SEO, à condition que les améliorations soient significatives.
Faut-il utiliser un CDN comme Cloudflare pour améliorer les Core Web Vitals de PrestaShop ?: Un CDN améliore principalement le TTFB (Time to First Byte) en servant le contenu depuis un serveur géographiquement proche de l'utilisateur. C'est bénéfique pour le LCP, surtout si votre audience est internationale. Cloudflare offre aussi la compression Brotli, la conversion WebP automatique (Polish) et le cache edge. Pour un site français avec un public majoritairement français, le gain est modéré (100-300 ms) mais réel.

Core Web Vitals PrestaShop : le protocole pour atteindre 90+ sur Google PageSpeed

Les 3 Core Web Vitals en 2026 : ce qui a changé pour PrestaShop

Les problématiques CWV typiques d'un PrestaShop non optimisé