Optimisation performances PrestaShop : modules lents, Core Web Vitals et bonnes pratiques

Chaque seconde de chargement en plus, c'est du chiffre d'affaires en moins. Les études le montrent de façon constante : au-delà de 3 secondes de chargement, plus de la moitié des visiteurs mobiles quittent la page. Et Google utilise les Core Web Vitals comme critère de classement SEO depuis 2021. Un site PrestaShop lent, c'est moins de visiteurs, moins de conversions, et un classement Google qui dégringole.

La bonne nouvelle, c'est que PrestaShop est une plateforme performante de base. La mauvaise, c'est qu'on peut facilement la rendre lente en empilant des modules mal optimisés, des images non compressées, et un hébergement sous-dimensionné. Voyons comment reprendre le contrôle.

Identifier les goulots d'étranglement

Côté serveur : le profiling PHP

La première étape est de mesurer. PrestaShop dispose d'un outil de profiling intégré qui affiche le temps d'exécution de chaque hook et de chaque module. En activant _PS_DEBUG_PROFILING_ dans config/defines.inc.php, vous obtenez un tableau complet : temps serveur, nombre de requêtes SQL, mémoire consommée, et surtout le détail par module.

C'est souvent révélateur : un module de statistiques qui exécute 200 requêtes SQL sur chaque page, un module de réseaux sociaux qui appelle 3 API externes en synchrone, un module de filtres qui recalcule tout à chaque chargement. En PrestaShop 9, le Symfony Profiler offre des outils encore plus fins pour tracer les performances.

Côté client : Google PageSpeed Insights

PageSpeed Insights mesure ce que vos visiteurs vivent réellement. L'outil analyse le LCP (temps d'affichage du plus grand élément visible), l'INP (réactivité aux interactions), et le CLS (stabilité visuelle). Il liste aussi les ressources qui bloquent le rendu : CSS non critique, JavaScript synchrone, images sans dimensions explicites.

Les 5 optimisations à fort impact

1. Désactiver les modules lents

Après le profiling, vous avez la liste des modules les plus gourmands. Certains sont indispensables et doivent être optimisés. D'autres sont installés par défaut et ne servent à rien : statsdata, statssearch, psgdpr (si vous avez votre propre solution RGPD). Désactiver un seul module peut réduire le temps de chargement de 200 à 500 ms.

2. Configurer le cache correctement

PrestaShop propose plusieurs niveaux de cache, mais beaucoup de boutiques ne les utilisent pas ou mal. Le cache Smarty doit être en mode "Compiler le cache" (pas "Forcer la compilation"). Le cache de requêtes SQL doit être activé. Et si votre hébergement le supporte, activez un cache objet avec Memcached ou Redis — le gain est souvent de 30 à 50% sur le temps serveur.

3. Optimiser les images

Les images représentent souvent 60 à 80% du poids d'une page e-commerce. Trois actions combinées font une différence massive : convertir en WebP (ou AVIF si le navigateur le supporte), redimensionner au plus juste (pas d'image 3000×3000 pour un affichage 400×400), et activer le lazy loading pour les images sous la ligne de flottaison.

4. Réduire le JavaScript bloquant

Chaque module PrestaShop peut ajouter son propre fichier JavaScript. Sur une boutique avec 30 modules actifs, ça représente facilement 15 à 20 scripts chargés sur chaque page, dont la plupart ne sont pas nécessaires immédiatement. La solution : identifier les scripts non critiques et les charger en defer ou async. Un module sur-mesure peut conditionner le chargement des scripts aux pages qui en ont réellement besoin.

5. Optimiser les requêtes SQL

Des requêtes SQL lentes peuvent transformer une page rapide en calvaire. Les coupables habituels : des SELECT * sur des tables volumineuses, des jointures sans index, des requêtes N+1 dans des boucles. L'ajout d'index ciblés et la réécriture des requêtes les plus lourdes peuvent diviser le temps de réponse par 2 ou 3.

L'hébergement : le socle de la performance

Un hébergement mutualisé à 5 €/mois ne tiendra pas la charge d'une boutique PrestaShop en production. Le minimum recommandé est un VPS avec 4 Go de RAM, PHP 8.2+ avec OPcache activé, MySQL 8 ou MariaDB 10.6+, et un serveur web Nginx (plus rapide qu'Apache pour les sites statiques et le proxy reverse).

Pour les boutiques à fort trafic (>100 000 visites/mois), un serveur dédié ou une architecture cloud avec CDN (Cloudflare, Fastly) devient pertinent. Le CDN sert les fichiers statiques depuis des serveurs géographiquement proches du visiteur — gain typique de 200 à 400 ms sur le premier affichage.

Core Web Vitals : les cibles

Google évalue trois métriques principales, et les cibles sont claires.

LCP (Largest Contentful Paint) < 2,5 secondes — C'est le temps d'affichage du plus grand élément visible (souvent l'image produit ou le slider). Pour l'améliorer : optimisez l'image hero, préchargez-la avec <link rel="preload">, et éliminez les ressources bloquantes.

INP (Interaction to Next Paint) < 200 ms — C'est la réactivité de la page aux clics et interactions. Les modules JavaScript lourds (filtres dynamiques, animations) sont souvent responsables des mauvais scores. Privilégiez les interactions côté serveur ou le JavaScript vanilla plutôt que jQuery.

CLS (Cumulative Layout Shift) < 0,1 — C'est la stabilité visuelle : la page ne doit pas "sauter" pendant le chargement. Les causes principales : images sans dimensions width/height, polices web qui changent la taille du texte, et bannières publicitaires injectées tardivement.