Optimiser les performances PrestaShop : configuration cache et serveur

Introduction

Le temps de réponse serveur est un facteur critique pour toute boutique e-commerce. Un objectif de temps de téléchargement HTML sous 300 ms est ambitieux mais réalisable avec les bons réglages. Après des années d'optimisation de boutiques PrestaShop — certaines avec plus de 5 000 références produit — voici une méthodologie éprouvée pour configurer le cache, le serveur et les modules afin d'obtenir des performances optimales.

Cet article couvre les réglages côté PrestaShop (cache Smarty, compression, médias) et côté serveur (OPcache, sous-domaines), avec des conseils adaptés de PrestaShop 1.6 jusqu'à la version 8.x.

Comprendre les couches de cache PrestaShop

PrestaShop dispose de plusieurs niveaux de mise en cache qui agissent à différents stades du rendu d'une page. Bien les comprendre permet de faire des choix éclairés plutôt que d'activer aveuglément toutes les options.

Le cache Smarty : un faux ami en phase de développement

Le moteur de templates Smarty (utilisé jusqu'en PrestaShop 1.7 — remplacé par Twig côté back-office en 8.x) propose plusieurs modes de cache :

• **Ne jamais recompiler les fichiers de template** : performances maximales, mais aucune modification de template n'est visible sans vider le cache manuellement.
• **Recompiler les templates s'ils ont été mis à jour** : bon compromis pour la production.
• **Forcer la compilation** : uniquement en développement.

Conseil important : en phase de test ou d'ajustement du contenu (par exemple lors d'une mise à jour massive via CSV), il est pertinent de désactiver le cache Smarty temporairement. Cela évite de servir des pages obsolètes pendant que vous affinez vos fiches produit. Réactivez-le une fois la phase de test terminée.

# PrestaShop 1.6/1.7 — Back-office > Paramètres avancés > Performances
# Cache Smarty : "Recompiler les templates s'ils ont été mis à jour"
# En production, c'est le réglage optimal.

Sur PrestaShop 8.x, le cache Smarty reste pertinent pour le front-office (les templates .tpl sont toujours utilisés côté client). Le réglage se trouve dans Paramètres avancés > Performances.

Réduction et compression du code

PrestaShop propose trois options de minification :

OptionRecommandationPourquoi Réduction du code HTML⚠️ À testerPeut casser certains modules mal codés Compression CSS✅ ActiverGain significatif sans risque Compression JavaScript⚠️ À testerPeut provoquer des erreurs JS sur certains thèmes

La compression JavaScript dans le code HTML (inline JS) est particulièrement risquée : certains modules injectent du JavaScript inline mal formé qui ne supporte pas la minification. Si vous observez des dysfonctionnements (carrousel bloqué, ajout au panier inopérant), désactivez cette option en premier.

// Exemple de code inline problématique qu'on rencontre souvent :
// Un point-virgule manquant avant une fonction auto-exécutée
var myVar = 'test'
(function() { /* ... */ })()  // TypeError après minification

Sur PrestaShop 8.x, privilégiez la combinaison et minification CSS/JS via des outils externes (Webpack, Vite) intégrés au thème plutôt que les options natives, qui restent basiques.

Configuration du cache serveur (APC / OPcache)

APC vs OPcache : le bon choix selon votre version PHP

• **APC** (Alternative PHP Cache) : adapté à PHP 5.x, utilisé historiquement avec PrestaShop 1.6.
• **OPcache** : intégré nativement depuis PHP 5.5, **c'est le standard actuel** pour PrestaShop 1.7+ et 8.x.

Si vous migrez depuis une ancienne version, le passage d'APC à OPcache est impératif.

; php.ini — Configuration OPcache recommandée pour PrestaShop 8.x
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=0

; En développement, réduire revalidate_freq à 0
; En production, 60 secondes est un bon compromis

Configuration du cache PrestaShop

Dans Paramètres avancés > Performances > Cache :

Système de cacheUsage recommandé Système de fichiersHébergement mutualisé (seule option souvent disponible) MemcachedServeur dédié, plusieurs frontaux **Redis****Recommandé** — rapide, persistant, polyvalent APC (déprécié)Anciennes installations PHP 5.x uniquement

// PrestaShop 8.x — Vérifier le cache actif
// Dans le back-office : Paramètres avancés > Performances
// Ou via la ligne de commande :
php bin/console cache:clear --env=prod

Serveur de médias : les sous-domaines statiques

Configurer un sous-domaine dédié aux fichiers statiques (images, CSS, JS) permet au navigateur d'ouvrir des connexions parallèles supplémentaires. C'est une technique simple mais efficace.

Mise en place

1. Créez un sous-domaine DNS (ex : `static1.votre-boutique.com`)
2. Pointez-le vers le même serveur (CNAME ou A record)
3. Dans PrestaShop : **Paramètres avancés > Performances > Serveurs de médias**
4. Renseignez le sous-domaine dans "Serveur de média 1"

# Configuration Apache pour le sous-domaine statique
<VirtualHost *:80>
    ServerName static1.votre-boutique.com
    DocumentRoot /var/www/prestashop

    # Désactiver PHP pour les fichiers statiques
    <Directory /var/www/prestashop/img>
        php_flag engine off
    </Directory>
    <Directory /var/www/prestashop/themes>
        php_flag engine off
    </Directory>

    # Headers de cache agressifs
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</VirtualHost>

Note pour PrestaShop 8.x : avec HTTP/2 (et a fortiori HTTP/3), le multiplexage rend les sous-domaines statiques moins nécessaires car le navigateur peut charger de nombreuses ressources en parallèle sur une seule connexion. Si votre serveur supporte HTTP/2, testez avec et sans sous-domaine — le gain peut être nul, voire négatif (à cause du coût DNS et TLS supplémentaire).

Optimisation des modules : le levier souvent négligé

Chaque module accroché à un hook front-office exécute du code PHP et potentiellement des requêtes SQL à chaque chargement de page. Sur une boutique avec 50 modules actifs, c'est un facteur de lenteur majeur.

Audit des modules front-office

-- Lister tous les modules accrochés aux hooks front-office
SELECT m.name, h.name AS hook_name, m.active
FROM ps_module m
JOIN ps_hook_module hm ON m.id_module = hm.id_module
JOIN ps_hook h ON hm.id_hook = h.id_hook
WHERE h.name LIKE 'displayHeader%'
   OR h.name LIKE 'displayTop%'
   OR h.name LIKE 'displayHome%'
   OR h.name LIKE 'displayFooter%'
ORDER BY h.name, m.name;

Règle d'or : désactivez tout module que vous n'utilisez pas activement en front-office. Les modules de statistiques internes (statsdata, statsvisits, etc.) sont particulièrement gourmands — préférez Google Analytics ou une solution externe.

Modules les plus impactants à désactiver

• `statsdata` / `statsvisits` / `statssearch` — remplacés par GA4 ou Matomo
• `blockwishlist` (si non utilisé)
• `productcomments` (si non utilisé)
• Tout module de chat/support non essentiel

Chiffrement et sessions : Blowfish vs autres algorithmes

Le choix de l'algorithme de chiffrement dans PrestaShop affecte marginalement les performances :

• **Blowfish** : rapide, adapté à PrestaShop 1.6. Déprécié depuis.
• **Rijndael (AES)** : utilisé par défaut dans les versions récentes, plus sécurisé.

Sur PrestaShop 8.x, le chiffrement utilise openssl avec AES-256-CBC par défaut. N'essayez pas de revenir à Blowfish — le gain de performance est négligeable et la sécurité serait dégradée.

// PrestaShop 8.x utilise PhpEncryption (OpenSSL)
// Vérifier dans config/parameters.php :
// 'cookie_key' => '...'
// La clé est générée à l'installation, ne la changez jamais en production

Gestion du contenu sur un catalogue volumineux

Avec un catalogue de 5 000 URL ou plus, la gestion du contenu devient un enjeu de productivité autant que de référencement.

Import CSV avec champs personnalisés

L'import CSV natif de PrestaShop permet de mettre à jour le contenu en masse. Pour ajouter un champ H1 personnalisé distinct du nom du produit :

// Override de ProductController pour utiliser un H1 custom
// classes/override/controllers/front/ProductController.php
class ProductController extends ProductControllerCore
{
    public function initContent()
    {
        parent::initContent();

        // Récupérer le H1 personnalisé depuis un champ feature
        $h1Custom = $this->product->getFeatures();
        // Logique de récupération du champ H1...

        $this->context->smarty->assign('custom_h1', $h1Custom);
    }
}

Sur PrestaShop 8.x, utilisez plutôt un module avec un hook actionProductFormBuilderModifier pour ajouter proprement un champ au formulaire produit, plutôt qu'un override.

Suivi SEO avec Google Search Console

Pour un catalogue volumineux, Google Search Console est indispensable pour :

• Identifier les pages non indexées
• Repérer les erreurs d'exploration
• Suivre l'évolution des mots-clés
• Détecter la **sur-optimisation** (keyword stuffing)

Comment détecter la sur-optimisation :

• Comparez le CTR de vos pages avec leur position moyenne. Un CTR anormalement bas pour une bonne position peut indiquer un titre/description sur-optimisé qui rebute les internautes.
• Surveillez les baisses soudaines de position : Google pénalise le keyword stuffing.
• Utilisez l'outil de couverture pour vérifier que vos pages riches en mots-clés sont bien indexées.

Checklist de performance PrestaShop

## Checklist rapide
- [ ] OPcache activé et configuré (256 Mo minimum)
- [ ] Cache Smarty en mode "recompiler si mis à jour"
- [ ] Combinaison CSS activée
- [ ] Combinaison JS activée (tester après activation)
- [ ] Modules front-office inutiles désactivés
- [ ] Modules de stats natifs désactivés (GA4 à la place)
- [ ] Redis ou Memcached configuré comme système de cache
- [ ] HTTP/2 activé sur le serveur web
- [ ] Compression Gzip/Brotli activée
- [ ] Images optimisées (WebP si possible)
- [ ] Serveur média configuré (ou HTTP/2 vérifié)
- [ ] CDN envisagé pour les sites à fort trafic

Conclusion

Optimiser les performances d'une boutique PrestaShop est un travail d'équilibre : chaque réglage doit être testé individuellement pour mesurer son impact réel. Les gains les plus significatifs viennent généralement de trois leviers : le cache serveur (OPcache/Redis), la désactivation des modules superflus, et la compression des assets. Sur PrestaShop 8.x, l'écosystème s'est modernisé (Symfony, HTTP/2, Doctrine cache), mais les fondamentaux restent les mêmes : mesurer, ajuster, valider.