Optimiser les performances de votre boutique PrestaShop : des requetes SQL au cache de page

Chaque 100ms de temps de chargement supplementaire vous coute des conversions. En e-commerce, la vitesse n'est pas un luxe – elle impacte directement votre chiffre d'affaires. Ce guide se concentre sur les optimisations specifiques et actionables qui font la plus grande difference pour les boutiques PrestaShop.

Commencez par mesurer

Avant d'optimiser quoi que ce soit, vous avez besoin d'une base de reference. Utilisez ces outils :

• Google PageSpeed Insights – fournit les Core Web Vitals (LCP, FID, CLS) et un score de performance
• GTmetrix – offre des graphiques en cascade montrant exactement ce qui se charge et quand
• MySQL slow query log – activez-le temporairement pour trouver les requetes de plus d'une seconde
• Xdebug profiler – pour l'identification des goulots d'etranglement au niveau PHP (utilisez cachegrind pour l'analyse)

Mesurez d'abord, optimisez ensuite, puis mesurez a nouveau. Sinon, vous devinez.

Optimisation de la base de donnees

La base de donnees est le goulot d'etranglement le plus courant dans PrestaShop. Voici ce qu'il faut verifier :

Indexez vos tables personnalisees

Si vos modules creent des tables personnalisees, assurez-vous qu'elles ont des index adequats. Un index manquant sur une colonne frequemment interrogee peut transformer une requete de 10ms en un scan de table de 3 secondes.

ALTER TABLE ps_my_module_data ADD INDEX idx_id_product (id_product);
ALTER TABLE ps_my_module_data ADD INDEX idx_date_add (date_add);

Nettoyez les anciennes donnees

PrestaShop accumule des donnees qui ralentissent tout au fil du temps :

• ps_connections et ps_connections_page – peuvent atteindre des millions de lignes
• ps_log – a tronquer regulierement
• ps_mail – les anciens enregistrements d'e-mails s'accumulent
• Les paniers abandonnes de plus de 30 jours – peuvent etre supprimes sans risque dans la plupart des cas

Optimisez les requetes

Utilisez EXPLAIN sur toute requete touchant de grandes tables. Surveillez type: ALL (scan complet de table) et Using temporary; Using filesort – les deux sont des signaux d'alerte.

PHP et OPcache

L'optimisation au niveau PHP est souvent negligee :

• PHP 8.2+ – nettement plus rapide que 7.4, et PrestaShop 8.x/9.x le supporte
• OPcache – activez-le et definissez opcache.revalidate_freq=60 en production (pas 0)
• Cache realpath – augmentez realpath_cache_size a 4096K pour les grandes boutiques
• Limite memoire – definir a au moins 512M pour eviter la pression du ramasse-miettes

Redis pour le cache et les sessions

Remplacez le cache base sur les fichiers par Redis :

• Le cache Smarty, le cache Symfony et les caches de modules beneficient tous de Redis
• Le stockage de sessions dans Redis elimine les problemes de verrouillage de fichiers en haute concurrence
• Une seule instance Redis peut gerer toutes ces charges pour une boutique typique

Optimisation front-end

• CCC (Combine, Compress, Cache) – activez-le dans les parametres de performance, mais testez soigneusement
• Lazy loading – utilisez le natif loading="lazy" sur les images produits
• Images WebP – 25-35% plus legeres que le JPEG a qualite equivalente
• CDN – dechargez les ressources statiques vers Cloudflare ou equivalent ; definissez l'URL du serveur media dans PrestaShop
• Critical CSS – integrez les styles above-the-fold en inline pour eliminer les requetes bloquant le rendu

Cache de page complet

Pour les boutiques a fort trafic avec des catalogues relativement statiques, un cache de page complet (Varnish ou nginx FastCGI cache) peut reduire les temps de reponse de 500ms a moins de 50ms. La partie delicate est l'invalidation du cache – il faut purger correctement quand les prix changent, les stocks sont mis a jour ou les promotions commencent et se terminent.

Commencez par les optimisations base de donnees et PHP – elles offrent les meilleurs resultats pour le moindre risque. Ajoutez le cache front-end et full page une fois la base solide.