Site lent sur PrestaShop - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant toute intervention, qualifie précisément où ça rame. Un TTFB front élevé, un back-office qui traîne et des pics aléatoires ne pointent jamais vers les mêmes causes — confondre les trois est la première erreur.

Utilise cet arbre de triage pour orienter le reste du diagnostic. C'est lui qui détermine quelles commandes lancer ensuite.

• Front lent en permanence (pages produits, catégories, accueil) → cache désactivé, assets non concaténés, requêtes catalogue non indexées, images lourdes. Va voir le profiler et la CCC.
• Back-office lent uniquement → statistiques natives actives, modules branchés aux hooks admin, table ps_log / ps_connections gonflée. Le front peut être correct.
• Lenteurs intermittentes / aléatoires → cron simultanés, cache qui se régénère, pic de trafic ou bots/scraping, hébergement mutualisé saturé par un voisin. Regarde les logs Apache/Nginx et le slow query log.
• TTFB > 1 s mesuré sur GTmetrix ou DevTools = problème serveur/applicatif confirmé (cible : < 600 ms).
• Le 1er chargement après une purge de cache est toujours plus lent (régénération) ; ne juge jamais une perf sur la première requête, recharge et mesure la seconde.

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s | Total: %{time_total}s\n' https://votre-boutique.com/
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s | Total: %{time_total}s\n' 'https://votre-boutique.com/2-accueil'

Impact business immédiat

La lenteur n'est pas un confort dégradé, c'est une fuite de chiffre d'affaires mesurable. Voici ce qui se dégrade pendant que le site rame, par ordre de gravité pour un marchand.

• Baisse du taux de conversion : l'abandon grimpe dès que le LCP dépasse 2,5 s sur mobile, là où se fait l'essentiel du trafic.
• Coût publicitaire par commande en hausse : un site lent dilapide le budget Google Ads / Meta — tu paies le clic mais la page perd le visiteur avant l'ajout panier.
• Perte de visibilité SEO : les Core Web Vitals (LCP, CLS, INP) sont un signal de classement ; un site lent recule sur les requêtes catalogue compétitives.
• Frustration et rebond : un back-office lent ralentit aussi ton équipe (saisie commandes, SAV) et coûte en productivité interne.

Causes classées par probabilité

Sur la base des audits PrestaShop, voici les causes triées de la plus fréquente à la plus rare. Inutile de partir sur l'hébergement (cause souvent surévaluée) tant que les quatre premières n'ont pas été écartées.

• 1. Cache mal configuré (très fréquent) — Smarty forcé à recompiler à chaque requête, CCC désactivée, aucun OPcache. Le cache corrompu après mise à jour représente à lui seul une grosse part des incidents.
• 2. Modules front trop nombreux ou mal codés — chaque module greffé sur displayHeader / displayFooter injecte ses JS/CSS et parfois une requête SQL bloquante. 30+ assets non critiques sur une fiche produit est courant.
• 3. Base de données obèse / non indexée — tables ps_log, ps_connections, ps_guest, ps_statssearch, ps_cart, ps_specific_price (souvent des centaines de milliers de lignes inutiles) ; requête catalogue sans index.
• 4. Images non optimisées — pas de WebP, pas de lazy load, vignettes non régénérées, fichiers de plusieurs Mo servis tels quels.
• 5. Version PHP ancienne — rester en 7.4 alors que PHP 8.x est jusqu'à 3× plus rapide ; absence d'OPcache.
• 6. Hébergement sous-dimensionné (souvent invoqué, rarement le vrai problème en premier) — mutualisé sans RAM dédiée, pas de Redis/Varnish, InnoDB sous-alloué.

Diagnostic : les commandes à lancer

L'objectif ici est de transformer « le site est lent » en « le hook X du module Y consomme 800 ms en base ». On active le profiler, on lit les logs, on traque les requêtes SQL lentes.

Étape 1 — Activer le profiler PrestaShop de façon sécurisée (jamais ouvert à tous en production, le mode profiling ajoute 30 à 50 % de surcoût). Édite config/defines.inc.php et restreins-le à ton IP :

Étape 2 — Recharge une fiche produit, puis ouvre la page : le profiler affiche le temps total, le nombre de requêtes SQL (50–150 par page est normal, > 200 est une alerte), le temps SQL (s'il dépasse 50 % du temps total, le problème est en base) et le détail hook par hook. Les hooks coupables récurrents côté admin : actionAdminControllerSetMedia, displayBackOfficeHeader, actionDispatcher.

Étape 3 — Traquer les requêtes SQL lentes côté MySQL (seuil 1 s, une requête > 100 ms est déjà lente) et identifier les tables obèses.

• Distinction importante : le mode debug (_PS_MODE_DEV_) affiche les erreurs PHP ; le profiling (_PS_DEBUG_PROFILING_) mesure les temps. Active le profiling seul pour mesurer, et coupe les deux en prod normale.
• En PrestaShop 8.x/9.x, le mode dev passe aussi par le fichier .env (APP_ENV=dev, APP_DEBUG=1) — repasse en prod avant d'ouvrir au public.

// Restreint le profiling à ta seule IP publique
if ($_SERVER['REMOTE_ADDR'] === 'VOTRE_IP_PUBLIQUE') {
    define('_PS_DEBUG_PROFILING_', true);
}
// Laisser le mode dev à false en production
define('_PS_MODE_DEV_', false);

# Erreurs et lenteurs applicatives récentes
tail -n 100 var/logs/prod.log        # PrestaShop 8.x / 9.x
tail -n 100 app/logs/prod.log        # PrestaShop 1.7

# Top 20 des IP qui frappent le serveur (détecter un bot/scraping)
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

-- Activer le slow query log (seuil 1 s)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- Tables les plus volumineuses du schéma PrestaShop
SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb,
       table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 15;

Solutions pas-à-pas

Applique dans cet ordre. Mesure le TTFB avant et après chaque action (commande curl de la première section) pour valider le gain — c'est ce qui distingue une optimisation d'un coup de dés.

1. Vider et reconfigurer le cache. Back-office : Paramètres avancés > Performances > Vider le cache. En CLI (voie moderne PS 8.x/9.x) : php bin/console cache:clear --env=prod. Manuel/FTP : vide /var/cache/ (PS 8.x/9.x) ou /cache/ (PS 1.7). Recharge deux fois avant de juger.
2. Régler le cache dans Paramètres avancés > Performances : « Ne jamais recompiler les fichiers de templates » en prod, cache « Système de fichier » (ou CacheApc si l'extension apcu est installée — sinon le message « vous devez installer l'extension APC PCEL » apparaît). Garde « Vider le cache à chaque modification » pour le catalogue.
3. Activer la CCC (Smart Cache) : concaténer + compresser CSS et JavaScript. ATTENTION : combiner le JS casse certains thèmes/modules. Active-la, navigue sur fiche produit, catégorie, panier et checkout ; si un slider ou un onglet ne répond plus, désactive le « combiner JS » seul en gardant la compression.
4. Désactiver les statistiques natives (gros gain back-office) : Modules > Gestionnaire de modules, désactive Visits and Visitors, Pages not found, Search engine keywords, Visitors Online, Best Categories/Customers/Suppliers/Selling Products, Data mining for statistics, Stats Dashboard.
5. Purger et optimiser la base. Sauvegarde d'abord, puis nettoie les tables d'historique et lance OPTIMIZE TABLE (voir code).
6. Passer à PHP 8.3/8.4 et activer OPcache (256 Mo mini). Règle memory_limit à 512M, max_execution_time à 300, realpath_cache_size à 4096K et realpath_cache_ttl à 600. Si tu as la main serveur, fixe l'InnoDB buffer pool à 60–70 % de la RAM.
7. Optimiser les images : régénère les vignettes (Design > Images > Régénérer), active le lazy load et sers en WebP. Compresse les visuels existants (TinyPNG ou conversion serveur).
8. Activer la compression Brotli (meilleure que Gzip, standard 2026) côté Nginx/Apache, et HTTP/2 ou HTTP/3. En option avancée : CDN (Cloudflare/BunnyCDN) et cache serveur Redis/Varnish une fois les bases faites.

-- Vider les tables d'historique qui gonflent inutilement
TRUNCATE TABLE ps_log;
TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_connections_source;
TRUNCATE TABLE ps_guest;
TRUNCATE TABLE ps_statssearch;

-- Paniers abandonnés très anciens (adapter la date)
DELETE FROM ps_cart WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

-- Défragmenter / recalculer les index
OPTIMIZE TABLE ps_cart, ps_specific_price, ps_search_index, ps_log, ps_guest;

php bin/console cache:clear --env=prod
# puis régénérer en frappant deux fois une page front
curl -o /dev/null -s https://votre-boutique.com/ && \
curl -o /dev/null -s -w 'TTFB après purge: %{time_starttransfer}s\n' https://votre-boutique.com/

Spécificités par version

Les chemins, la voie CLI et les versions PHP recommandées diffèrent nettement selon la branche. Vérifie ta version dans Configuration avant d'appliquer une commande.

• PrestaShop 1.7.x : cache dans /cache/, logs dans app/logs/, PHP 7.4+ recommandé (7.4 minimum sur 1.7.8). Pas de bin/console fiable partout — privilégie back-office et FTP.
• PrestaShop 8.x : cache dans /var/cache/, logs dans var/logs/prod.log, mode dev via .env, PHP 8.1/8.2/8.3. bin/console cache:clear disponible.
• PrestaShop 9.x : socle Symfony 6.4, PHP 8.1 minimum et compatible 8.3/8.4 (PHP 8.x est jusqu'à 3× plus rapide que 7.4). C'est la branche qui tire le meilleur des optimisations OPcache et du moteur récent.
• Sur serveur dédié/VPS, neutraliser l'appel distant aux Addons (qui ajoute une latence réseau) via un override : override/classes/Tools.php, surcharge addonsRequest() pour retourner false. Ne touche jamais au cœur, passe toujours par /override.
• Core Web Vitals à viser (valeurs 2026) : LCP < 2,5 s, CLS < 0,1, INP < 200 ms (l'INP a remplacé le FID — ne te fie pas aux vieux guides qui citent encore « FID < 100 ms »), FCP < 1,8 s, score PageSpeed mobile > 70.

Quand appeler un expert

La majorité des gains (cache, CCC, purge BDD, PHP 8.3) se font en interne avec ce guide. Fais appel à un expert quand le diagnostic dépasse l'auto-dépannage ou quand le risque business est trop élevé pour expérimenter en production.

BugRescue, l'expertise de Soulaimane Aattar (fondateur), intervient sur ces cas : lecture fine du profiler hook par hook, optimisation SQL (index manquants, requêtes catalogue lourdes), mise en place Redis/Varnish, et arbitrage migration vs optimisation pour récupérer un maximum de performance sans refonte lourde.

• Le profiling pointe un hook ou une requête SQL que tu n'arrives pas à isoler, ou le temps SQL dépasse 50 % sans coupable évident.
• Lenteurs intermittentes inexpliquées malgré logs propres (suspicion de saturation hébergement, cron mal réglés ou scraping).
• La CCC ou un changement de version casse le thème et tu ne peux pas te permettre une boutique instable.
• Tu hésites entre migrer (hébergement, PS 9) et optimiser : un audit ciblé tranche en quelques heures et évite une migration coûteuse inutile.

FAQ