Comment améliorer les Core Web Vitals d'une boutique PrestaShop ?

En corrigeant dans cet ordre : les images, souvent l'élément le plus lent de la page, puis le cache et la compression, les scripts des modules, et enfin les dimensions réservées. Google juge une page « bonne » quand 75 % des visites passent trois seuils : affichage principal (LCP) en 2,5 secondes ou moins, réactivité (INP) de 200 millisecondes ou moins, stabilité (CLS) de 0,1 ou moins. En 2024, seuls 43 % des sites mobiles y parvenaient.

Sur PrestaShop, les Core Web Vitals sont le terrain où beaucoup de boutiques perdent des points sans le savoir : thèmes lourds, modules empilés, images non optimisées. Trois métriques suffisent à savoir où vous en êtes.

Que mesurent les trois Core Web Vitals ?

• LCP (Largest Contentful Paint) : le temps avant l'affichage du plus gros élément visible. Sur 73 % des pages mobiles, cet élément est une image : sur une boutique, la bannière ou la photo produit. Objectif : 2,5 s ou moins. C'est la métrique la plus liée au ressenti « le site est lent », et la plus souvent ratée : en 2024, 59 % des sites mobiles passaient le seuil.
• INP (Interaction to Next Paint) : la réactivité, le délai entre un clic et la réponse visible de la page. Objectif : 200 ms ou moins. L'INP a remplacé le FID comme Core Web Vital le 12 mars 2024.
• CLS (Cumulative Layout Shift) : la stabilité visuelle, les éléments bougent-ils pendant le chargement ? Objectif : 0,1 ou moins. Le coupable classique est une image ou un bloc sans dimensions réservées.

Mesurez-les sur des données réelles plutôt que sur un seul test synthétique : le seuil se juge au 75ᵉ percentile des chargements, séparément sur mobile et sur ordinateur. C'est ce que montre le rapport Core Web Vitals de la Search Console, et c'est l'expérience de vos vrais visiteurs qui compte.

Les Core Web Vitals comptent-ils pour le référencement ?

Oui, comme critère de départage. Google écrit qu'ils s'alignent sur « ce que nos systèmes de classement principaux cherchent à récompenser », mais précise aussi que son moteur « cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de la page est médiocre ». La vitesse fait la différence entre deux pages également pertinentes, pas au-delà.

L'enjeu le plus net est commercial. Dans l'étude Milliseconds Make Millions, menée par Deloitte pour Google sur 37 marques et plus de 30 millions de sessions mobiles, un site plus rapide de 0,1 seconde a vu ses conversions retail progresser de 8,4 % et son panier moyen de 9,2 %.

Pourquoi les boutiques PrestaShop ratent-elles souvent les seuils ?

Quatre causes récurrentes :

1. Images non compressées et mal dimensionnées. Une photo produit de 2 Mo servie en pleine résolution plombe le LCP. Le WebP est 25 à 34 % plus léger qu'un JPEG de qualité équivalente, selon Google.
2. Modules JavaScript en excès. Chaque module ajoute son JS ; empilés, ils dégradent l'INP. Auditez et désactivez l'inutile.
3. Thème lourd. Les thèmes premium multiplient sliders et polices. Chaque police web et chaque slider a un coût.
4. Pas de cache ni de compression. Une boutique qui recompile ses gabarits à chaque visite part avec un handicap sur tout le reste.

S'y ajoute, sur les vieilles versions, le plafond de PHP : une 1.6.1 ne dépasse pas PHP 7.1, ce qui limite ce que l'hébergement peut rattraper. Le cas est traité dans PrestaShop 1.6 et SEO.

Dans quel ordre corriger ?

Ne corrigez pas tout en même temps, priorisez par impact :

1. Les images d'abord (LCP). WebP, dimensions adaptées à l'affichage, chargement différé sous la ligne de flottaison. Attention à une exception : web.dev recommande de [retirer le loading="lazy" de l'image LCP](https://web.dev/articles/top-cwv) et de lui donner fetchpriority="high". Différer la photo principale d'une fiche produit, c'est retarder exactement ce que Google mesure.
2. Le cache et la compression ensuite : cache Smarty en mode production, combinaison et minification CSS/JS dans le back-office, compression gzip ou brotli côté serveur. Effet immédiat sur tout le site.
3. La chasse aux modules JS (INP) : plus long, mais nécessaire si l'interactivité rame.
4. Les dimensions et la réservation d'espace (CLS) : rapide, souvent oublié. Selon web.dev, 66 % des pages contiennent au moins une image sans dimensions, qui s'affiche à 0 pixel de haut puis repousse le reste. Des attributs width et height sur chaque image suffisent.

La performance dispense-t-elle du contenu ?

Non. Un site rapide mais vide ne se classe pas davantage : la vitesse départage, elle ne génère pas de trafic. Le guide SEO PrestaShop pose le socle, les données structurées enrichissent les résultats, et le contenu (blog et fiches) apporte les visiteurs.

Bon à savoir : un blog servi par un module léger n'alourdit pas la boutique, contrairement à une solution externe bourrée de scripts, un point à vérifier dans la compatibilité PrestaShop.

FAQ

Les Core Web Vitals sont-ils un facteur de classement ? Oui, mais secondaire. Google les décrit comme alignés sur ce que ses systèmes de classement récompensent, tout en précisant qu'il montre toujours le contenu le plus pertinent, même si l'expérience de la page est médiocre. À pertinence égale, le plus rapide passe devant.

Qu'est-ce que l'INP, qui a remplacé le FID ? L'Interaction to Next Paint mesure le délai entre une interaction (clic, tap, touche) et la réponse visible de la page, sur l'ensemble de la visite. Il a remplacé le First Input Delay comme Core Web Vital le 12 mars 2024. Le seuil « bon » est de 200 millisecondes ou moins.

Où voir les Core Web Vitals de ma boutique ? Dans le rapport Core Web Vitals de la Search Console, qui s'appuie sur les visites réelles, séparément pour mobile et ordinateur. PageSpeed Insights affiche les mêmes données de terrain pour une URL donnée, au-dessus du test de laboratoire.

Faut-il un score PageSpeed de 100 ? Non. Le score de laboratoire sert au diagnostic ; ce qui compte pour Google, ce sont les données réelles, et la Web Almanac rappelle que le score Lighthouse n'influence pas directement ces données de terrain. Viser « bon » sur les trois métriques suffit.

Faut-il activer le lazy loading sur toutes les images ? Sur toutes, sauf la plus grande image visible au chargement. Différer l'image LCP retarde son affichage : web.dev recommande au contraire de la charger en priorité.

En bref

LCP, INP, CLS : mesurez sur données réelles, corrigez les images en premier (sans différer la photo principale), puis cache, scripts et dimensions. La vitesse départage à pertinence égale et se traduit en conversions. Elle ne remplace ni le SEO de fond ni le contenu, qui fait venir les visiteurs.