Boutique PrestaShop lente : trouver la cause et accélérer le front et le back-office
Une boutique PrestaShop lente pénalise directement le chiffre d'affaires : fiches produit longues à s'afficher, panier qui met du temps à se mettre à jour, tunnel de commande abandonné. Côté back-office, un catalogue lourd rend la gestion des produits, des commandes et des stocks pénible pour vos équipes.
PrestaShop est plus exigeant que la moyenne des CMS : chaque page front combine des dizaines de hooks de modules, des requêtes SQL sur les tables produits, combinaisons, prix spécifiques et stocks, et un rendu Smarty. Un serveur sous-dimensionné, des modules mal écrits, un cache désactivé ou une base de données non entretenue se font sentir rapidement.
Cette page décrit les causes les plus fréquentes de lenteur sur PrestaShop 1.6, 1.7 et 8, les vérifications que vous pouvez faire dans le back-office et sur le serveur, et les solutions à appliquer, du réglage du cache à l'optimisation de la base de données.
Symptômes typiques
- Les pages catégorie et les fiches produit mettent plusieurs secondes à s'afficher, surtout avec des filtres à facettes.
- L'ajout au panier, la mise à jour des quantités ou le passage à l'étape de livraison sont lents.
- Le back-office est lent à ouvrir la liste des produits, des commandes ou à enregistrer une fiche produit.
- La lenteur s'aggrave avec le nombre de produits, de déclinaisons ou de règles de prix.
- Le serveur affiche une charge CPU ou MySQL élevée dès qu'il y a un peu de trafic.
- Les temps de réponse mesurés par PageSpeed Insights ou WebPageTest sont élevés dès le premier octet (TTFB).
Causes possibles
Modules lents ou trop nombreux
Chaque module accroché sur les hooks de la page exécute du code et des requêtes. Les modules de navigation à facettes, de statistiques, de blocs produits (nouveautés, meilleures ventes) et certains modules tiers sont les plus coûteux.
Cache Smarty et cache applicatif mal configurés
Compilation Smarty forcée à chaque appel, cache désactivé, ou fonctionnalités de performance (CCC, combinaison et compression des fichiers) non activées multiplient le travail à chaque page.
Base de données volumineuse et non entretenue
Tables ps_connections, ps_connections_source, ps_guest, ps_cart, ps_log et ps_statssearch qui grossissent sans purge, index manquants sur des tables produits importantes, absence d'optimisation des tables.
Catalogue complexe
Des milliers de déclinaisons, des prix spécifiques par groupe et par pays, des règles de panier nombreuses, des caractéristiques abondantes multiplient les requêtes SQL nécessaires pour calculer un prix ou un stock.
Images non optimisées
Images produits en très haute définition, absence de WebP, régénération de miniatures manquante ou trop de formats d'image générés.
Serveur ou version de PHP inadaptés
Hébergement mutualisé, PHP non maintenu, absence d'OPcache, MySQL avec des paramètres par défaut (innodb_buffer_pool_size trop bas) et pas de cache mémoire.
Appels externes bloquants
Modules qui interrogent des services tiers (transporteurs, marketplaces, avis clients, ERP) de manière synchrone à chaque affichage de page.
Contrôles à effectuer
- 1
Activer le profiling PrestaShop
Dans config/defines.inc.php, passez _PS_DEBUG_PROFILING_ à true sur une copie ou hors trafic : un rapport en bas de page détaille le temps par hook, par module et par requête SQL, ainsi que la mémoire consommée.
- 2
Vérifier les réglages de performance
Paramètres avancés > Performance : cache Smarty en mode « Ne jamais recompiler les fichiers de template », cache activé, CCC activé, mode debug désactivé en production.
- 3
Mesurer le poids de la base de données
Dans phpMyAdmin, triez les tables par taille. Des tables ps_connections, ps_guest ou ps_log de plusieurs centaines de mégaoctets sont un signal clair de nettoyage nécessaire.
- 4
Activer le journal des requêtes lentes MySQL
Avec slow_query_log activé et long_query_time réglé bas, le fichier de log liste les requêtes les plus longues ; EXPLAIN sur ces requêtes révèle les index manquants.
- 5
Désactiver les modules non essentiels
Sur une copie de test, désactivez les modules un par un en observant le profiling pour identifier ceux qui coûtent le plus.
- 6
Contrôler le serveur
top ou htop pour la charge, free -m pour la mémoire, df -h pour l'espace disque, et la version de PHP avec php -v. Vérifiez qu'OPcache est activé via un fichier phpinfo() temporaire.
- 7
Tester avec et sans cache
Comparez le temps de réponse d'une même page à froid puis à chaud dans l'onglet Réseau du navigateur. Si le temps reste identique, le cache ne fonctionne pas.
Solutions
Régler correctement les caches
Smarty en recompilation désactivée, cache applicatif activé, OPcache configuré avec suffisamment de mémoire, et un cache mémoire (Redis, Memcached) pour les boutiques à fort trafic.
Nettoyer et indexer la base de données
Purge régulière des tables de connexions, invités, paniers abandonnés anciens et logs, ajout d'index sur les requêtes lentes identifiées, OPTIMIZE TABLE, et réglage d'InnoDB.
Rationaliser les modules
Supprimer les modules inutilisés (pas seulement les désactiver), remplacer les modules lourds, désactiver les modules de statistiques natifs si un outil externe est utilisé.
Optimiser les images
Compression et WebP, régénération des miniatures dans les bons formats, suppression des formats non utilisés et chargement différé.
Rendre asynchrones les appels externes
Synchronisations ERP, avis clients et flux marketplaces déplacés vers des tâches cron plutôt qu'exécutés à chaque affichage.
Mettre à niveau l'infrastructure
PHP maintenu, MySQL ou MariaDB réglé (innodb_buffer_pool_size adapté aux données), Nginx avec PHP-FPM, CDN pour les fichiers statiques, et migration vers un serveur dimensionné si nécessaire.
Quand contacter un professionnel ?
- Le profiling montre des requêtes SQL lentes issues du cœur ou de modules que vous ne pouvez pas modifier.
- La lenteur touche le tunnel de commande et se traduit par des abandons de panier mesurables.
- Votre catalogue compte des milliers de références ou de déclinaisons et les optimisations standard ne suffisent plus.
- Vous n'avez pas d'environnement de test ni d'accès serveur pour effectuer les réglages en sécurité.
- Vous préparez une montée en charge (campagne, soldes, marketplace) et voulez sécuriser la boutique avant.
L'intervention proposée par Agencei
- 1
Audit de performance
Profiling PrestaShop, journal des requêtes lentes, analyse des modules et de la configuration serveur, mesures depuis l'extérieur.
- 2
Optimisation applicative
Réglage des caches, tri et remplacement des modules, corrections ciblées dans les surcharges et les modules sur mesure, asynchronisation des appels externes.
- 3
Optimisation de la base de données
Nettoyage, index, réglage InnoDB, automatisation des purges.
- 4
Optimisation serveur
PHP-FPM, OPcache, Nginx, Redis, CDN, dimensionnement et, si besoin, migration vers un hébergement adapté.
- 5
Mesures et rapport
Comparaison des temps avant et après sur les pages clés (accueil, catégorie, produit, panier, commande) et recommandations pour la suite.
- 6
Maintenance
Suivi régulier avec mises à jour testées, surveillance et nettoyage périodique pour conserver les gains.
Questions fréquentes
Pourquoi le back-office est-il si lent alors que le front va bien ?
Le front bénéficie des caches, pas le back-office. Les listes de produits et de commandes exécutent des requêtes lourdes sur des tables volumineuses ; des modules chargés sur toutes les pages d'administration et une base de données non nettoyée aggravent le phénomène.
Un module de cache suffit-il ?
Il aide pour les pages statiques mais pas pour le panier, le compte client ou le tunnel de commande, qui sont dynamiques. La base de données, les modules et le serveur doivent aussi être optimisés.
Faut-il mettre à jour PrestaShop pour gagner en performance ?
Les versions récentes apportent des améliorations, mais la migration est un projet à part entière. Une boutique 1.6 ou 1.7 bien optimisée peut être rapide ; la mise à jour se décide sur d'autres critères (sécurité, compatibilité des modules, fonctionnalités).
Combien de temps dure une optimisation ?
Le diagnostic prend souvent quelques heures. Les corrections vont de quelques heures pour les caches et la base de données à plusieurs jours si des modules doivent être remplacés ou le serveur migré.
Le nettoyage de la base de données est-il risqué ?
Pas s'il est fait avec une sauvegarde préalable et en ciblant les tables techniques (connexions, invités, logs, paniers anciens). Les données de commandes et de clients ne sont jamais concernées.
Services associés
Optimisation performance
Diagnostic par profilage et corrections ciblées : Core Web Vitals, requêtes SQL, cache, CDN.
Voir ce serviceMaintenance PrestaShop
Mises à jour testées, sauvegardes, surveillance et sécurité pour une boutique PrestaShop toujours ouverte.
Voir ce serviceAgence PrestaShop
Modules et thèmes PrestaShop sur mesure, reprise de boutiques 1.6, 1.7 et 8, performance et intégrations.
Voir ce serviceAudit technique
Revue indépendante du code, de l'architecture et de l'infrastructure, avec un rapport priorisé.
Voir ce serviceParlez-nous de votre projet
Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.