PrestaShop 8 & 1.7 : Optimisation du Cache Smarty et Diagnostic des Modules Lents

PrestaShop est la solution e-commerce historique en France, propulsant des dizaines de milliers de boutiques en ligne. Bien que robuste, le moteur de templates Smarty et l’accumulation de modules tiers (marketplace addons) dégradent fréquemment les performances en production.

Un constat typique : après l’installation de modules marketing ou de livraison, le Time to First Byte (TTFB) des pages catégories dépasse 2.500 millisecondes, et le serveur dédié sature à 100% d’utilisation CPU.

Ce runbook présente les réglages critiques pour maîtriser le moteur Smarty et isoler les modules défaillants.

1. Réglages Essentiels Smarty dans le Back-Office

Rendez-vous dans Paramètres Avancés > Performances :

1. Compilation des templates : Choisissez impérativement :
   • Ne jamais recompiler les fichiers de templates (L’option “Recompiler si mis à jour” force un stat() sur chaque fichier template à chaque visite, ruinant les I/O disque !)
2. Cache : Activé (OUI).
3. Type de mise en cache : Système de fichiers ou Redis (si configuré).
4. Effacement du cache : Ne jamais vider le cache automatiquement ou Vider uniquement les éléments modifiés.

2. Profilage Chirurgical avec le Profiler Natif de PrestaShop

Pour savoir quel module monopolise les ressources du serveur, activez temporairement le mode Debug ou le profiler dans config/defines.inc.php :

// config/defines.inc.php
define('_PS_MODE_DEV_', false);
define('_PS_DEBUG_PROFILING_', true); // Active le bandeau d'audit en bas de page

Rechargez une page catégorie lente. Le tableau récapitule :

• Total Time & Memory : Temps d’exécution total de PHP.
• Hook Processing : Temps consommé par chaque hook (displayHeader, actionProductListOverride).
• Tableau des Modules : Permet d’identifier immédiatement le module responsable (ex: un module de filtres ou de slider carrousel consommant 1.200ms à lui seul !).

[!IMPORTANT] N’oubliez jamais de repasser _PS_DEBUG_PROFILING_ à false une fois le diagnostic terminé.

3. Mise en Cache des Requêtes de Configuration dans Redis

Dans PrestaShop, la méthode Configuration::get() interroge continuellement la table ps_configuration. Déportez le cache d’objets vers Redis :

Dans app/config/parameters.php (ou dans le back-office sous Serveur de cache) :

'cache' => [
    'enabled' => true,
    'adapter' => 'cache.adapter.redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => 6379,
        'database' => 1
    ]
],

4. Nettoyage de la Table ps_connections et des Paniers Abandonnés

Une base de données PrestaShop vieillissante accumule des millions de lignes de statistiques de connexion qui ralentissent toutes les requêtes :

-- Nettoyage des anciennes connexions statistiques (+ de 180 jours)
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 180 DAY);
DELETE FROM ps_connections_source WHERE id_connections NOT IN (SELECT id_connections FROM ps_connections);

-- Optimisation des tables
OPTIMIZE TABLE ps_connections, ps_connections_source, ps_cart;

5. Résultats Obtenus

Une boutique réactive, un tunnel de commande instantané et des coûts d’infrastructure réduits sur vos serveurs français.

🔗 Diagnostics Techniques & Maillage d’Architecture :

Les goulots d’étranglement d’infrastructure ne sont jamais isolés. La latence serveur, les requêtes SQL et le rendu DOM interagissent en continu :

• Navigation à Facettes PrestaShop & Budget de Crawl: Empêcher l’indexation de millions d’URLs combinatoires par Googlebot.
• Cache d’Objets Redis Persistant pour WordPress & WooCommerce: Soulager le serveur SQL des requêtes de sessions et métadonnées répétitives.
• Correction des Sauts de Mise en Page (CLS) Colissimo & Mondial Relay: Stabiliser le rendu visuel des widgets de points relais dans le tunnel d’achat.