Optimiser les performances PrestaShop

Le problème à résoudre

Une boutique PrestaShop combine catalogue, recherche, promotions, stocks, sessions et paiement. Une page rapide hors connexion ne suffit pas : le panier et la commande doivent rester stables sous charge.

Mesurez séparément accueil, catégorie, fiche produit, recherche, panier et administration. Chaque gabarit active des modules et requêtes différents.

Reconnaître les bons signaux

Signal observé	Interprétation probable	Premier contrôle
Catégorie lente	Facettes, tri ou requêtes catalogue	Profiler la requête et les modules
Panier lent	Règles de prix ou transporteurs	Tester chaque étape
Back-office saturé	Imports, indexation ou tâches	Planifier et superviser les jobs

Les notions à maîtriser

Le cache de page doit exclure le contenu personnalisé et les sessions.
Les images produits nécessitent des formats et dimensions adaptés à chaque vue.
Les modules de tracking, paiement et transport ajoutent des appels externes.
Les tables volumineuses et index inadaptés se révèlent sous une charge réaliste.

Méthode de diagnostic

1. Créer une référence sur six parcours incluant une commande de test.

2. Profiler PHP et SQL avec les modules réellement actifs.

3. Contrôler cache Smarty, OPcache, workers FPM et buffer pool SQL.

4. Mesurer les tâches d’import, réindexation et génération de miniatures.

Plan d’action recommandé

Mettre à jour PrestaShop et les modules sur préproduction.
Retirer les modules inutilisés et limiter les hooks coûteux.
Optimiser images, lazy loading et cache navigateur.
Corriger les requêtes lentes avant d’augmenter les ressources.
Tester la montée en charge avec un scénario sans paiement réel.

Inventaire avant mesure

Depuis la racine de la boutique, ces commandes donnent une première vue des volumes et des modules installés sans modifier l’application.

du -sh img var/cache modules 2>/dev/null
find modules -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort
find img -type f | wc -l

Complétez avec la version de PrestaShop, PHP et MariaDB, puis testez les mêmes parcours avant et après. Un module présent n’est pas nécessairement actif : confirmez dans le back-office.

Erreurs fréquentes à éviter

Mettre le panier ou le compte client en cache public.
Désactiver les contrôles de sécurité pour gagner quelques millisecondes.
Lancer imports et sauvegardes pendant le pic commercial.

Indicateurs à suivre

Indicateur	Repère	Pourquoi le suivre
Temps fiche produit	Stable au p95	Représente le catalogue
Temps panier	Compatible avec la conversion	Mesure le parcours critique
Requêtes SQL lentes	Aucune récurrente non expliquée	Cible l’optimisation

Checklist avant validation

Une mesure de référence est conservée.
Le changement est testé hors production lorsque c’est possible.
Une sauvegarde ou un retour arrière est disponible.
Les dépendances web, e-mail et DNS ont été contrôlées.
Les journaux et alertes sont surveillés après intervention.
Le résultat est documenté avec date et responsable.

Questions fréquentes

Un CDN suffit-il ?

Non. Il accélère les médias, mais pas les calculs de panier ou les requêtes SQL.

Peut-on cacher toutes les pages ?

Non : compte, panier, commande et contenus personnalisés doivent être traités avec prudence.

Quand changer de serveur ?

Après avoir mesuré une saturation réelle et éliminé les problèmes applicatifs majeurs.

Sources techniques

Pour vérifier les règles et approfondir le sujet :

Besoin d’optimiser une boutique PrestaShop ?

Catalogue, SQL, PHP-FPM, cache et modules doivent être mesurés sur les parcours qui génèrent réellement des commandes.

Voir l’hébergement PrestaShop