# 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.

- Source canonique : [https://allaux.fr/prestashop/boutique-lente](https://allaux.fr/prestashop/boutique-lente)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Regardez d’abord Paramètres avancés > Performances : cache des templates sur « ne jamais recompiler », mode debug désactivé, combinaison CSS et JS active. Vérifiez ensuite côté serveur qu’OPcache tourne et sur quelle version de PHP. Si la lenteur ne bouge pas, le problème est en base : relevez les requêtes lentes de MySQL et les index manquants sur ps_product et ps_category_product.

## Comment je mesure avant d’intervenir

1. **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.
2. **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).
3. **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.
4. **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.
5. **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.

## Site PrestaShop lent : le serveur ou le navigateur ?

Avant de corriger quoi que ce soit, il faut savoir si le temps se perd sur le serveur ou dans le navigateur. Ouvrez les outils de développement du navigateur, onglet Réseau, et regardez la première ligne : le temps d’attente de la réponse du serveur, le TTFB.

TTFB élevé, au-delà d’une seconde environ : le serveur met du temps à fabriquer la page. La cause est en PHP, en base de données ou dans un module, et c’est l’objet de cette page.

TTFB correct mais page longue à s’afficher : le serveur répond vite, le navigateur peine ensuite. Images trop lourdes, scripts tiers (messagerie, avis, suivi publicitaire), polices et JavaScript non différés : c’est un travail sur le front, pas sur le serveur.

Seul le back-office est lent : regardez les listes de commandes, de produits ou de clients sur de gros volumes, les modules du tableau de bord, et la taille des tables de statistiques comme ps_connections, ps_guest ou ps_pagenotfound, qui grossissent sans limite quand rien ne les purge.

## Les réglages oubliés qui ralentissent toute la boutique

Une part étonnante des boutiques lentes que je vois n’ont aucun problème de code : un réglage de dépannage est resté actif.

_PS_MODE_DEV_ laissé à true dans config/defines.inc.php après une intervention. Sur 1.7, 8 et 9, il fait aussi tourner le back-office dans l’environnement de développement de Symfony, nettement plus lent.

_PS_DEBUG_PROFILING_ activé : chaque page calcule et affiche son propre profil, ce qui a un coût à chaque affichage.

Dans Paramètres avancés > Performances, la compilation des templates réglée sur « Forcer la compilation » : Smarty recompile les gabarits à chaque affichage au lieu de les réutiliser.

Le cache désactivé dans ce même écran, parfois pour « voir une modification » et jamais réactivé.

Ces quatre points se vérifient en quelques minutes et ne demandent aucun développement. Ils passent avant toute conclusion sur l’hébergement.

## 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.

## Changer d’hébergement ne suffit pas toujours

> Un serveur plus puissant masque un problème de requêtes mal indexées pendant un temps, mais la lenteur revient dès que le catalogue ou le trafic augmente. Je préfère corriger la cause avant de recommander une montée en gamme serveur.

## Pages liées

- **Diagnostiquer une boutique lente** — La méthode de mesure pas à pas, avant de toucher à quoi que ce soit. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Les modules qui ralentissent la boutique** — Repérer les modules qui s’exécutent sur chaque page sans raison. ([/modules/modules-qui-ralentissent-la-boutique](/modules/modules-qui-ralentissent-la-boutique))
- **Performance d’un gros catalogue PrestaShop** — Ce qui change au-delà de plusieurs dizaines de milliers de références. ([/expertises/performance-catalogue-volumineux-prestashop](/expertises/performance-catalogue-volumineux-prestashop))
- **Site lent du jour au lendemain** — Quand le ralentissement a une date précise, la cause aussi. ([/problemes/site-lent-depuis-hier](/problemes/site-lent-depuis-hier))
- **Filtres de catégorie disparus** — La recherche à facettes et son index, souvent en cause sur les pages catégorie. ([/prestashop/problemes/filtres-page-categorie-disparus](/prestashop/problemes/filtres-page-categorie-disparus))
- **Refaire le site pour la lenteur ?** — Rarement la bonne réponse : ce qu’une refonte règle, et ce qu’elle reproduit. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Faut-il changer d’hébergeur pour résoudre la lenteur ?

Pas systématiquement. Je commence par mesurer où le temps est réellement perdu : souvent la cause est dans le code ou la base, pas dans la puissance du serveur.

### L’audit de performance va-t-il ralentir ou risquer la boutique en ligne ?

Non, le profilage se fait sans interrompre le site. Les modifications de correction sont testées avant d’être appliquées en production, et je peux intervenir hors heures de forte affluence si besoin.

### Quels accès dois-je vous fournir ?

Un accès FTP ou SSH, un accès à la base de données, et si possible un accès à l’espace d’administration de l’hébergement pour vérifier la configuration PHP et le cache disponible.

### Combien de temps prend un audit de performance ?

Le diagnostic prend en général une demi-journée à une journée. Les corrections varient ensuite selon leur nature : un ajout d’index se fait en quelques minutes, une refonte de module mal optimisé prend plus de temps.

### Est-ce que ça va améliorer mon référencement ?

La vitesse de chargement fait partie des critères pris en compte par Google (Core Web Vitals), donc oui, indirectement, mais ce n’est pas une garantie de meilleur classement à elle seule.

### Pourquoi mon site PrestaShop est-il devenu lent du jour au lendemain ?

Une lenteur brutale a presque toujours une cause datée : mode debug resté actif après une intervention, module installé ou mis à jour, version de PHP changée par l’hébergeur, table de statistiques qui a franchi un seuil, ou afflux de robots. Rapprochez la date du ralentissement des dernières interventions et des journaux d’accès avant de toucher au serveur.