Développement PrestaShop

Ce qui ralentit vraiment PrestaShop : base de données, modules et hébergement

David Miller Publié : 02 mars 2026 Mis à jour : 25 août 2026 Développement PrestaShop

146 vues 19 min de lecture

PrestaShop n’est pas lent par nature. Une installation propre en 1.7, 8.x ou 9.x, avec un catalogue raisonnable et une liste de modules maîtrisée, répond largement en moins d’une seconde. Quand une boutique se met à traîner, le diagnostic « PrestaShop est lourd » est donc presque toujours faux : quelque chose de précis ralentit cette boutique, et cela se trouve à l’un de trois endroits : la base de données, les modules ou l’hébergement. Le piège dans lequel tombent la plupart des marchands consiste à traiter les trois à la fois, acheter Redis, changer d’hébergeur et désactiver la moitié des modules dans la panique, sans jamais savoir ce qui leur coûtait réellement ces secondes. Ce guide parle d’attribution : comment regarder une boutique PrestaShop lente et identifier la couche responsable, afin de consacrer vos efforts là où le temps est vraiment perdu.

Les correctifs eux-mêmes ont chacun leur article dans ce dossier, nous les signalerons au fil du texte. Ici, vous trouverez la partie que personne n’écrit vraiment : comment déterminer, sur votre propre boutique, lequel des trois facteurs vous ralentit.

Revu pour PrestaShop 1.7, 8.x et 9.x. Une précision honnête pour les versions récentes : le JIT de PHP 8 et OPcache expliquent l’essentiel du gain qui donne l’impression qu’un PrestaShop récent est plus rapide, et le passage de PS9 à Symfony 6.4 allège la compilation du conteneur, mais ces améliorations concernent la couche hébergement/PHP, pas une base de données gonflée ni un module qui boucle sur des requêtes. Mettre à niveau la plateforme ne remplace jamais l’identification de la vraie cause ci-dessous.

Pourquoi « c’est lent » désigne trois problèmes totalement différents

La lenteur est un symptôme, et ce même symptôme peut avoir trois causes sans rapport entre elles, que l’on corrige de trois façons différentes. Traiter la mauvaise cause, c’est gaspiller de l’argent. Voici comment chaque couche échoue, ce que l’on ressent côté boutique et où le temps part réellement :

Couche	Ce qui cloche vraiment	Le symptôme révélateur	Ce que cela vous coûte
Base de données	Tables gonflées, index manquants, requêtes lourdes à chaque demande	Réponse serveur lente (TTFB), qui empire avec la taille du catalogue ou l’historique des commandes ; back-office lent aussi	Chaque page, chaque visiteur, y compris le robot de Google
Modules	Trop de hooks exécutés par page, appels à des API externes au chargement, scripts redondants	Un type de page (souvent produit ou catégorie) beaucoup plus lent que le reste ; de nombreuses requêtes front-end	Rendu front-end et TTFB ; cela empire à chaque module ajouté
Hébergement	CPU/RAM partagés et saturés, pas d’OPcache, disques mécaniques, MySQL sous-dimensionné	Tout est lent et irrégulier, rapide à 3 h du matin, poussif aux heures de pointe ; back-office et front-office touchés de la même façon	Une taxe fixe sur chaque requête, dont aucun cache ne vous libère complètement

Et alors ? Si le problème vient de la base de données, un serveur plus rapide ne changera presque rien : vous exécuterez simplement les mêmes requêtes lentes sur une machine un peu plus rapide. Si le problème vient de la contention de l’hébergement, nettoyer la base ne vous protégera pas du voisin qui lance une sauvegarde à 17 h. Tout l’enjeu consiste à faire correspondre le correctif à la cause.

Première étape : séparer la chronologie entre « serveur » et « navigateur »

Avant d’accuser une couche, vous devez savoir si le temps est perdu côté serveur (PrestaShop construit la page) ou côté navigateur (téléchargement et rendu). Cette seule séparation vous envoie sur deux pistes différentes.

Le chiffre qui les distingue est le TTFB, Time to First Byte : le temps que met le serveur à commencer à répondre. Sur une boutique PrestaShop saine, le TTFB reste sous environ 300 ms ; au-delà d’une seconde, le côté serveur est en difficulté. Tout ce qui vient après le premier octet, images, CSS, JavaScript, polices, relève du navigateur et du front-end.

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://www.example.com/category-url

TTFB élevé, rendu rapide une fois la page arrivée → la cause est côté serveur : base de données ou hébergement (lisez la suite pour distinguer les deux).
TTFB bas, mais la page semble encore lente à apparaître → la cause est front-end : généralement des modules qui empilent les requêtes, auxquels s’ajoutent les images et les ressources.

Nous ne reprendrons pas ici toute la mécanique de mesure : tester le TTFB par type de page, lire les Core Web Vitals (LCP, INP, CLS) et savoir à quoi ressemble un « bon » chiffre sont expliqués en détail dans votre boutique est-elle lente ? comment vérifier et quoi faire. Faites-le d’abord ; revenez avec un chiffre de TTFB et le type de page le plus mauvais. Le reste de ce guide interprète ces deux informations.

Est-ce la base de données ? La cause la plus courante, et la mieux cachée

D’après notre expérience d’exploitation et de correction de boutiques PrestaShop, la base de données est la source la plus fréquente de lenteur côté serveur, et la plus sous-estimée, parce qu’elle ne laisse aucune trace évidente dans le navigateur. Les indices :

Le TTFB augmente à mesure que la boutique vieillit, tout allait bien au lancement, puis la situation s’est dégradée sans changement évident. C’est le gonflement des tables : ps_connections, ps_connections_source, ps_guest, ps_statssearch, ps_pagenotfound et ps_log grossissent indéfiniment et sont interrogées pour les statistiques. Les anciennes lignes de paniers abandonnés dans ps_cart ne disparaissent pas toutes seules.
Le back-office est lent lui aussi, pas seulement la boutique côté client. Un pur problème d’hébergement ou de front-end épargne généralement l’administration ; un problème de base de données touche les deux, car les deux exécutent les mêmes requêtes sur les mêmes grosses tables.
La même table revient encore et encore dans le journal des requêtes lentes (réglez long_query_time sur une valeur basse et observez). Les récidivistes sans index sur les colonnes utilisées dans WHERE/JOIN sont la preuve à charge : une requête instantanée sur 1 000 lignes devient douloureuse sur 1 000 000.

Le correctif se divise clairement. Réduire le gonflement est la moitié facile et très rentable, et c’est un sujet complet à part entière : consultez nettoyage de la base de données : pourquoi votre boutique ralentit avec le temps pour savoir ce que l’on peut supprimer sans risque et ce qu’il faut conserver. L’autre moitié, plus profonde, optimisation des requêtes, index et association du nettoyage avec le cache, est traitée dans optimiser les performances de votre boutique : des requêtes de base de données au cache pleine page.

Si vous préférez ne pas lancer vous-même des instructions DELETE ni configurer le cron, notre module Database Cleanup applique depuis le back-office une version sûre par défaut, paniers expirés, anciennes statistiques de recherche, enregistrements invités et connexions, journaux obsolètes, selon une planification, afin que les tables n’aient plus l’occasion de gonfler. Et alors ? Le TTFB qui montait mois après mois cesse de grimper, sans que vous touchiez au SQL ni que vous deviez penser à le faire.

Onglet de configuration de Database Cleanup avec un interrupteur Activer l'espace de nettoyage réglé sur oui, un encadré indiquant que le module est installé et prêt, et un bouton pour ouvrir l'espace de nettoyage

L’onglet de configuration affiche l’espace de nettoyage activé et le module marqué comme installé et prêt.

SELECT table_name, table_rows, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name IN ('ps_connections', 'ps_connections_page', 'ps_guest', 'ps_cart', 'ps_log', 'ps_search_index')
ORDER BY (data_length + index_length) DESC;

Est-ce les modules ? La mort par mille hooks

La différence entre une boutique PrestaShop rapide et une boutique lente tient, plus souvent qu’à tout autre facteur isolé, aux modules, en particulier au nombre d’entre eux qui s’exécutent sur chaque page et à ce qu’ils font pendant ce temps. Les signes sont différents de ceux de la base de données :

Un type de page est nettement plus lent que les autres, les pages produit traînent alors que la page d’accueil va bien, par exemple. Cela pointe vers un module accroché à cette page (un vérificateur de stock en temps réel, une vente croisée qui calcule des relations, un widget d’avis) plutôt que vers un problème serveur général.
Beaucoup de requêtes front-end et du JavaScript lourd dans le panneau réseau, souvent depuis des domaines tiers. C’est la signature front-end d’une prolifération de modules.
La boutique a ralenti juste après l’installation de quelque chose. Le test le plus propre de tout ce guide : désactivez un module suspect, mesurez à nouveau, puis réactivez-le. Activez le Profiler (définissez _PS_DEBUG_PROFILING_ sur true dans config/defines.inc.php sur une copie de préproduction), puis lisez sa sortie pour inspecter le temps d’exécution des hooks et le nombre de requêtes SQL par module : c’est ainsi que vous repérez celui qui ajoute 200 ms à chaque chargement. La page Paramètres avancés → Performances elle-même sert aux réglages liés au cache et au débogage, pas aux résultats de profilage.

Ce qu’il faut surveiller précisément :

Trop de hooks. Chaque module présent sur displayHeader, displayTop, displayFooter ou actionFrontControllerSetMedia s’exécute sur absolument chaque page. Trente modules à cet endroit, c’est trente fonctions lancées avant même qu’un seul pixel soit rendu.
Appels à des API externes au chargement de la page. Un tarif transporteur récupéré en direct, un taux de change demandé à chaque affichage, un flux social appelé en temps réel : chacun ajoute 200 à 500 ms de latence réseau, et si ce service tombe, votre page attend avec lui. Le correctif est toujours le même : mettre le résultat en cache localement et l’actualiser par cron, jamais pendant la requête du visiteur.
Modules redondants. Deux modules SEO, trois traceurs analytiques, deux bannières de cookies : chacun taxe chaque page. Un module bien choisi vaut mieux que trois qui se disputent la même tâche ; auditez et supprimez les doublons.

Pour un exemple concret de ce que cela peut donner dans le bon sens, une vraie boutique PrestaShop 9 avec plus de 130 modules et pourtant un score de 99/100, consultez PageSpeed 99/100 sur une vraie boutique avec plus de 130 modules. La leçon est rassurante : le nombre de modules n’est pas l’ennemi, la discipline des modules l’est.

Est-ce l’hébergement ? La taxe fixe qu’aucun cache n’efface

L’hébergement est la couche que les marchands accusent en premier et diagnostiquent en dernier, souvent parce que le correctif coûte de l’argent. Les signes honnêtes indiquant qu’il s’agit réellement de votre problème, et non d’un bouc émissaire :

Les performances varient selon l’heure de la journée. Rapide à 3 h du matin, poussif à 18 h sans changement de trafic de votre côté. C’est le cas classique de contention CPU/RAM sur hébergement mutualisé : la charge de vos voisins déborde sur votre boutique.
Le TTFB reste élevé même sur une page propre, avec le cache chaud et la base déjà allégée. Si vous avez exclu les deux autres causes et que le serveur répond encore lentement, la machine sous-jacente est la limite.
OPcache est désactivé. C’est le réglage d’hébergement isolé qui a le plus d’impact sur PrestaShop : il conserve en mémoire le bytecode PHP compilé afin que les fichiers ne soient pas réanalysés à chaque requête, et il représente une part importante de votre TTFB. Vérifiez opcache.enable=1, avec opcache.memory_consumption=256 et opcache.max_accelerated_files=20000. Ne définissez opcache.validate_timestamps=0 que si vos déploiements réinitialisent ensuite PHP-FPM/OPcache de façon fiable ; sinon, gardez la validation des horodatages avec un opcache.revalidate_freq raisonnable, faute de quoi vous servirez du PHP périmé après une mise à jour de module, de cœur ou de thème.

Une boutique PrestaShop sérieuse a besoin, au minimum, d’un VPS ou d’un serveur dédié (pas d’un hébergement mutualisé saturé), de stockage SSD, de PHP 8.1+ avec OPcache, et de MySQL 8.0 / MariaDB 10.6+ avec innodb_buffer_pool_size ajusté à votre RAM. Mais « acheter un plus gros serveur » est la version paresseuse de ce conseil, et une grande partie de ce que vendent les hébergeurs relève du marketing. Les caractéristiques qui font réellement avancer PrestaShop, et celles qui ne sont que de la vente additionnelle, méritent leur propre décision, détaillée dans choisir un hébergement pour PrestaShop : ce qui compte et ce qui relève du marketing. Redimensionnez le serveur après avoir nettoyé les deux autres couches, pas avant, sinon vous paierez chaque mois pour exécuter les mêmes requêtes lentes un peu plus vite.

Où le cache aide, et où il n’aide pas

Le cache est la réponse réflexe à la lenteur, et c’est une bonne réponse pour la bonne cause ; mais il masque les problèmes aussi souvent qu’il les résout. Il a donc sa place à la fin de ce guide, pas au début. Un cache dissimule une base de données lente aux visiteurs anonymes ; il ne fait rien pour le client connecté, le panier, le tunnel de commande ou le back-office, qui touchent toujours la vraie requête.

Deux types comptent, et ils correspondent à deux des couches ci-dessus :

Cache objet (Redis / Memcached) cible la couche base de données : lorsque le cœur et les modules utilisent les API de cache de PrestaShop, il peut accélérer les recherches répétées et cacheables, et réduire la surcharge du cache sur système de fichiers. Ce n’est pas pour autant un cache SQL universel : il ne met en cache que les valeurs explicitement stockées via ces API, donc beaucoup de requêtes continuent de toucher MySQL. C’est le changement le plus impactant que vous puissiez faire si votre diagnostic ci-dessus pointe vers la base de données. La configuration et les gains réalistes sont expliqués dans cache Redis pour PrestaShop : configuration et gains de performance, avec le raisonnement sur son intérêt dans Redis : l’accélération dont votre boutique a probablement besoin. Notre module Redis Cache Manager & Monitor configure et surveille les réglages Redis nécessaires depuis le back-office si vous préférez ne pas modifier la configuration à la main.
Cache pleine page sert une page HTML préconstruite aux visiteurs anonymes, de sorte que PrestaShop ne construit rien du tout, le plus gros gain isolé pour le TTFB de la boutique sur le trafic éligible au cache. Il n’est pas intégré au cœur ; les options de modules, avec leurs compromis réels autour de l’invalidation du cache, sont comparées dans cache PrestaShop : les modules de cache pleine page expliqués.

Et les fonctions intégrées que vous devriez déjà avoir activées quoi qu’il arrive : le cache Smarty avec Forcer la compilation : Non, et CCC (Combiner, Compresser, Mettre en cache) pour CSS/JS : tous deux sous Paramètres avancés → Performances. Ils sont gratuits, livrés avec la plateforme, et un nombre étonnant de boutiques les laissent désactivés.

Si vous préférez ne pas assembler Redis, cache fragmenté, optimisation des ressources et supervision pièce par pièce, notre module MPR Performance Revolution les regroupe derrière un seul panneau de back-office. Qu’est-ce que cela vous apporte concrètement ? Les couches de cache à fort impact sont activées ensemble, avec une supervision qui confirme qu’elles répondent réellement. Vous ne devinez donc pas si le cache est chaud.

La checklist qui commence par le diagnostic

Mis bout à bout, l’ordre qui vous évite le plus d’efforts inutiles est simple : mesurer, attribuer, puis corriger la couche que vous avez réellement identifiée, pas les trois par principe.

1. Mesurez. Relevez le TTFB et le chargement complet sur la page d’accueil, une catégorie chargée et une page produit. (Méthode : votre boutique est-elle lente ?)
2. Séparez serveur et navigateur. TTFB élevé → serveur (base de données/hébergement). TTFB bas, rendu lent → front-end (modules/ressources).
3. Si c’est côté serveur, distinguez base de données et hébergement. Back-office lent + tables qui grossissent avec le temps + récidivistes dans le journal des requêtes lentes = base de données. Variations selon l’heure + OPcache désactivé + boutique propre mais encore lente = hébergement.
4. Si c’est front-end, isolez le module. Un type de page beaucoup plus lent → profilez les hooks, désactivez le suspect et mesurez à nouveau.
5. Corrigez la couche trouvée avec le guide correspondant, pas avec une dispersion de correctifs sur les trois.
6. Ajoutez le cache en dernier, adapté à la cause : cache objet pour un goulot d’étranglement de base de données, cache pleine page pour le TTFB de la boutique.
7. Mesurez à nouveau par rapport à votre référence. Si le chiffre n’a pas bougé, vous avez traité la mauvaise couche : revenez à l’étape 3.

La performance n’est pas une correction ponctuelle. Une boutique rapide à 500 produits mérite un nouvel examen à 5 000 ; une liste de modules qui était légère l’an dernier a pu grossir discrètement. Mais la discipline qui garde une boutique PrestaShop rapide n’a rien d’exotique : elle consiste à refuser de deviner. Identifiez laquelle des trois couches vous coûte réellement ces secondes, corrigez celle-là, mesurez, puis recommencez. « PrestaShop est lent » est presque toujours faux. « La base de données de cette boutique gonfle depuis trois ans », ou « ces quatre modules appellent chacun une API sur la page produit », ou « cet hébergement mutualisé est survendu ». L’une de ces phrases est vraie, et on peut la trouver en un après-midi.

Questions fréquentes

Le back-office est lent lui aussi. Est-ce que cela réduit les possibilités ?

Oui, c’est l’un des indices les plus utiles dont vous disposez. Un pur goulot d’étranglement d’hébergement ou un problème front-end/module épargne généralement l’administration, parce que le back-office charge des pages différentes et moins de scripts de la boutique. Quand l’administration est lente elle aussi, les deux côtés exécutent les mêmes requêtes sur les mêmes grosses tables, ce qui pointe fortement vers la base de données. Confirmez avec le journal des requêtes lentes : la même table qui apparaît sans cesse sans index est votre preuve à charge.

Une page produit est lente, mais la page d’accueil va bien. Où chercher ?

Cette asymétrie pointe presque toujours vers un module accroché à cette page précise : un vérificateur de stock en temps réel, une vente croisée qui calcule des relations, un widget d’avis qui lance une requête par élément. Un problème serveur ou d’hébergement général ralentit tout de manière uniforme ; une seule page lente est la signature d’un module. Activez le profiler, lisez les temps par hook et désactivez le suspect pour mesurer à nouveau. L’écart avant/après correspond exactement à ce que ce module vous coûte.

Redis corrigera-t-il un goulot d’étranglement de base de données ?

En partie, et seulement si le diagnostic pointe réellement vers la base de données. Le cache objet (Redis/Memcached) accélère les recherches répétées et cacheables, et supprime la surcharge du cache sur système de fichiers, mais ce n’est pas un cache SQL universel : il ne met en cache que les valeurs explicitement stockées via les API de cache de PrestaShop, donc beaucoup de requêtes touchent encore MySQL. Élaguez d’abord les tables gonflées et ajoutez les index manquants ; ajoutez Redis sur une base saine, où il rapporte vraiment au lieu de masquer un scan.

Est-il prudent de tout contourner avec le cache ?

Un cache pleine page est le plus gros gain isolé pour le TTFB de la boutique, mais il ne sert que les visiteurs anonymes. Il ne fait rien pour le client connecté, le panier, le tunnel de commande ou le back-office, qui touchent toujours la vraie requête. Et vous ne devez jamais mettre en cache les pages panier/commande/connexion elles-mêmes : une page de commande en cache peut montrer à un client le panier d’un autre. Mettez en cache l’enveloppe de la boutique, laissez les routes dynamiques actives, et traitez le cache comme la dernière étape, pas la première.

Je suis passé à PrestaShop 9 / PHP 8 et c’est toujours lent. Pourquoi ?

Parce que les mises à niveau de version améliorent la couche PHP et plateforme, JIT, OPcache, compilation moins coûteuse du conteneur Symfony 6.4, pas la base de données. Si votre vraie cause est trois ans de gonflement de ps_connections ou quatre modules qui appellent chacun une API sur la page produit, la plateforme plus récente exécute exactement les mêmes problèmes sur une machine plus rapide. Attribuez d’abord la couche ; la mise à niveau aide la partie qui n’a jamais été votre goulot d’étranglement.