Votre boutique PrestaShop met trop de temps à charger
Une boutique lente ne se règle pas en changeant d’hébergement au hasard. La lenteur vient presque toujours d’un point précis : requêtes SQL non indexées, cache Smarty mal configuré, ou un module qui exécute du code inutile sur chaque page.
Comment je mesure avant d’intervenir
-
Profilage de la page
J’active le débogueur de performance pour lister les requêtes SQL exécutées sur une page donnée, leur nombre et leur temps d’exécution. Une fiche produit qui déclenche plus de 200 requêtes n’est pas normale.
-
Vérification du cache
Je contrôle l’état du cache Smarty (compilation et cache de rendu) et, sur PrestaShop 1.6, l’activation de la combinaison et compression CSS/JS (CCC).
-
Analyse des index MySQL
Je regarde les requêtes lentes côté base et j’ajoute les index manquants sur les tables les plus sollicitées, typiquement ps_product, ps_product_attribute et ps_category_product.
-
Audit des modules
Je repère les modules qui s’accrochent à des hooks exécutés sur chaque page (displayHeader, actionFrontControllerSetMedia) et qui font des appels externes ou des requêtes non nécessaires.
-
Vérification serveur
Je vérifie la présence d’OPcache, la version PHP utilisée et si un système de cache mémoire (Redis ou Memcached) est disponible pour remplacer le cache fichier par défaut.
Les signaux qui justifient un audit
- Fiche produit ou page catégorie qui met plus de 3 secondes à s’afficher
- Back-office qui devient lent dès que le catalogue dépasse quelques milliers de références
- Ralentissement progressif au fil des mois sans changement apparent
- Pic de lenteur uniquement pendant les périodes de forte affluence
- Score PageSpeed ou Core Web Vitals mauvais malgré un hébergement correct
Ce que je corrige le plus souvent
Le cache fichier par défaut de PrestaShop (var/cache) tient très bien sur un catalogue de quelques centaines de produits, mais devient un goulot d’étranglement sur un gros catalogue avec beaucoup de trafic simultané, car chaque écriture de cache verrouille le disque. Passer sur un cache mémoire change souvent la donne sans toucher au code.
Côté base de données, l’absence d’index sur les colonnes utilisées dans les jointures (id_product, id_shop, id_lang) fait exploser le temps de réponse dès que le catalogue grossit, alors que la même page reste rapide en environnement de test avec peu de données.
Enfin, certains modules de recommandation, de tracking marketing ou de génération de PDF exécutent du code lourd sur chaque affichage de page, y compris quand la fonctionnalité n’est pas utilisée à ce moment-là. Je les identifie via le débogueur de hooks et je propose soit une désactivation conditionnelle, soit un passage en tâche asynchrone.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.