Diagnostiquer et résoudre la lenteur d'un site PrestaShop

Introduction

Un site PrestaShop qui met plusieurs secondes à charger, c'est un signal d'alarme à ne pas ignorer. Au-delà de l'expérience utilisateur dégradée, la lenteur impacte directement votre référencement (Core Web Vitals) et votre taux de conversion. Un temps de réponse HTML supérieur à 2-3 secondes indique un problème côté serveur qu'il faut diagnostiquer méthodiquement.

Dans cet article, je vous présente ma méthode complète pour identifier et corriger les causes de lenteur sur PrestaShop, de l'analyse réseau jusqu'à l'optimisation des requêtes SQL.

Étape 1 : Mesurer objectivement le temps de réponse

Avant toute intervention, il faut quantifier le problème. Ouvrez les outils de développement de votre navigateur (F12), onglet Réseau, puis rechargez votre page.

Concentrez-vous sur la première requête (le document HTML) et observez la colonne Temps ou Durée. Un temps de téléchargement HTML supérieur à 500 ms au second chargement (cache navigateur actif) révèle un problème côté serveur.

Ce qu'il faut regarder

• **TTFB (Time To First Byte)** : le temps avant que le serveur commence à répondre. Au-delà de 800 ms, c'est problématique.
• **Temps de téléchargement total du HTML** : inclut le TTFB + le transfert. Au-delà de 1-2 secondes, il y a un goulet d'étranglement.
• **Nombre de requêtes** : un excès de fichiers CSS/JS (souvent causé par des modules) ralentit le rendu.

Vous pouvez également utiliser curl en ligne de commande pour une mesure précise :

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://votre-site.com

Étape 2 : Activer le Debug Profiling de PrestaShop

Le profiling intégré à PrestaShop est l'outil le plus puissant pour identifier les modules et requêtes SQL responsables de la lenteur.

Sur PrestaShop 1.6

Éditez le fichier config/defines.inc.php et modifiez la constante :

define('_PS_DEBUG_PROFILING_', true);

Sur PrestaShop 1.7 et 8.x

La méthode a évolué. Éditez le même fichier config/defines.inc.php :

define('_PS_DEBUG_PROFILING_', true);

Sur PrestaShop 8.x, vous pouvez également utiliser la Debug Toolbar Symfony en activant le mode debug dans .env :

APP_DEBUG=1
APP_ENV=dev

⚠️ Important : activez le profiling uniquement en environnement de développement ou après avoir mis votre site en maintenance. Le profiling ralentit considérablement le site et expose des informations techniques sensibles.

Interpréter les résultats du profiling

Une fois activé, rechargez n'importe quelle page de votre boutique. Un tableau détaillé s'affiche en bas de page avec :

• **Les hooks et modules** : temps d'exécution de chaque module sur chaque hook. Un module qui prend plus de 100 ms sur un hook est suspect.
• **Les requêtes SQL** : liste complète avec le temps d'exécution de chacune. Triez par durée pour identifier les requêtes lentes.
• **La mémoire consommée** : pic de consommation PHP.

Recherchez en priorité :

1. Les modules dont le temps cumulé dépasse 200 ms
2. Les requêtes SQL sans index (temps > 50 ms)
3. Les requêtes dupliquées (même requête exécutée des dizaines de fois)

Étape 3 : Vérifier la table ps_configuration

Un bug bien connu de PrestaShop 1.6.1.x (et qui peut persister lors de migrations vers 1.7/8.x) provoque une inflation anormale de la table ps_configuration. Cette table, normalement limitée à quelques centaines de lignes, peut atteindre plusieurs dizaines de milliers d'entrées parasites.

Diagnostiquer le problème

SELECT COUNT(*) FROM ps_configuration;

Si le résultat dépasse 1 000 à 1 500 lignes, il y a probablement un problème. Identifiez les entrées suspectes :

SELECT name, COUNT(*) as nb
FROM ps_configuration
GROUP BY name
HAVING nb > 5
ORDER BY nb DESC;

Nettoyer les doublons

La table ps_configuration est chargée intégralement en mémoire à chaque requête PHP. Des milliers de lignes superflues impactent donc chaque page.

-- Sauvegarde préalable OBLIGATOIRE
CREATE TABLE ps_configuration_backup AS SELECT * FROM ps_configuration;

-- Suppression des doublons en conservant la dernière valeur
DELETE c1 FROM ps_configuration c1
INNER JOIN ps_configuration c2
WHERE c1.id_configuration < c2.id_configuration
AND c1.name = c2.name;

Conseil : faites toujours un dump complet de votre base avant ce type d'opération.

Étape 4 : Autres causes fréquentes de lenteur

Modules gourmands

Désactivez temporairement vos modules tiers un par un (en commençant par les modules de statistiques, de filtres produits et de SEO) pour mesurer l'impact de chacun sur le TTFB.

Cache PrestaShop désactivé

Vérifiez dans Paramètres avancés > Performances :

• **Cache Smarty** : Activé, en mode "Ne jamais recompiler"
• **Concaténation CCC** : CSS et JS concaténés et minifiés
• **Cache serveur** : Activez Memcached ou Redis si disponible

Sur PrestaShop 8.x, la configuration du cache Symfony est également importante :

# config/packages/prod/framework.yaml
framework:
    cache:
        app: cache.adapter.redis
        # ou cache.adapter.memcached

Configuration PHP

Vérifiez votre configuration PHP, notamment :

; php.ini recommandé pour PrestaShop
memory_limit = 512M
max_execution_time = 300
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0  ; en production uniquement

L'activation d'OPcache seule peut réduire le TTFB de 30 à 50 %.

Base de données mal optimisée

Lancez une optimisation des tables :

-- Identifier les tables fragmentées
SELECT TABLE_NAME, DATA_FREE, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'votre_base'
AND DATA_FREE > 1048576
ORDER BY DATA_FREE DESC;

-- Optimiser les tables fragmentées
OPTIMIZE TABLE ps_cart, ps_connections, ps_guest, ps_log, ps_statssearch;

Tables de logs et statistiques surdimensionnées

Les tables de statistiques PrestaShop grossissent indéfiniment et ne sont jamais purgées automatiquement :

-- Vérifier la taille des tables problématiques
SELECT TABLE_NAME, 
       ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS taille_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'votre_base'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

Les tables ps_connections, ps_connections_source, ps_guest, ps_log et ps_statssearch peuvent souvent être purgées sans impact fonctionnel.

Étape 5 : Mesurer l'amélioration

Après chaque correction, mesurez à nouveau le TTFB pour quantifier le gain. Documentez vos résultats pour identifier les actions les plus efficaces. Visez un TTFB inférieur à 300 ms et un temps de chargement total sous les 2 secondes.

Récapitulatif de la méthode

1. **Mesurer** : outils navigateur + curl pour objectiver le problème
2. **Profiler** : activer `_PS_DEBUG_PROFILING_` pour identifier les coupables
3. **Vérifier** : table `ps_configuration`, modules lents, cache désactivé
4. **Optimiser** : purger les tables, activer OPcache, configurer Redis
5. **Valider** : re-mesurer et confirmer l'amélioration