Stratégie de cache PrestaShop 2026 : Redis, Memcached, Varnish — quelle stack pour quelle boutique

Sur une boutique PrestaShop 8 ou 9 non optimisée, le TTFB (Time To First Byte) dépasse couramment 800 ms sur du mutualisé et reste autour de 400 ms sur un VPS milieu de gamme. Effet direct sur le LCP (mauvais score Core Web Vitals), sur le budget de crawl Googlebot et sur le taux de rebond. Le tout en 2026, alors que le bench Google est passé à 200 ms de TTFB et 2,5 s de LCP.

Le cache n’est ni un sujet de niche ni réservé aux gros volumes. C’est l’optimisation à plus fort ROI sur PrestaShop, et celle qui est la plus mal faite : confusion entre cache PHP, cache objet, cache HTTP et reverse proxy ; configurations par défaut peu efficaces ; piles de modules qui se marchent sur les pieds. Cet article fait le point sur les quatre couches d’un stack propre et donne la règle de décision Redis / Memcached / Varnish selon le profil de boutique.

Les quatre couches de cache d’une boutique PrestaShop

Une boutique sert chaque page en empilant plusieurs couches de cache. Connaître les couches, c’est éviter d’en empiler plus qu’il n’en faut — chaque couche ajoute de la complexité et des points de purge à maîtriser.

1. Cache opcode PHP

OPcache met en cache le bytecode des fichiers .php interprétés. Indispensable : sans OPcache, chaque requête PrestaShop ré-interprète des milliers de fichiers. Gain typique : 30 à 50 % de TTFB. C’est gratuit, natif PHP, et c’est le premier réflexe à valider via php -i | grep opcache en production. À dimensionner : 256 Mo minimum pour PrestaShop 8/9, opcache.validate_timestamps=0 en production avec recyclage manuel sur déploiement.

2. Cache objet (in-memory key-value)

PrestaShop met en cache certains résultats applicatifs : sessions utilisateurs, métadonnées Smarty (chemins de templates, configuration de hooks), résultats de requêtes répétitives. Par défaut, ces caches passent par le système de fichiers, lent. En production sérieuse, on les déplace vers une base in-memory : Redis ou Memcached.

3. Cache HTTP et reverse proxy

Au-dessus de PrestaShop, un reverse proxy (Varnish, NGINX cache, ou edge cache CDN) intercepte les requêtes HTTP et sert des réponses pré-rendues sans solliciter PHP. C’est l’optimisation au plus fort levier — gain typique de 90 % du temps serveur sur les pages anonymes en hit cache.

4. Cache navigateur et CDN

Les ressources statiques (images, CSS, JS, polices) doivent porter des en-têtes Cache-Control: public, max-age=31536000, immutable et être servies par un CDN. Évidence en 2026, mais mal faite sur 40 % des boutiques auditées : max-age trop court, ressources non versionnées, variations de cache mal configurées.

Redis vs Memcached : la décision en pratique

Sur le cache objet, deux choix dominent : Redis et Memcached. Le débat « lequel est plus rapide » est dépassé — les deux saturent largement les besoins d’une boutique PrestaShop. La vraie différence est ailleurs.

Memcached

• Plus simple, moins de fonctionnalités, moins de surface d’attaque et moins de pièges de configuration.
• Excellent pour du cache éphémère key-value pur.
• Pas de persistance disque : un redémarrage vide tout, ce qui produit un thundering herd transitoire sur PHP-FPM.
• Pas de structures avancées (listes, sorted sets, pub-sub) — usage limité au cache strict.

Redis

• Plus riche : structures de données (lists, sets, sorted sets), pub-sub, scripting Lua.
• Persistance optionnelle (RDB ou AOF) : survit aux redémarrages.
• Utilisé bien au-delà du cache PrestaShop : sessions multi-serveurs, queue Symfony Messenger, rate limiting.
• Configuration mémoire à surveiller (maxmemory, eviction policy) — sinon il consomme plus que prévu.

Règle pratique 2026 : Redis est le choix par défaut. Memcached reste pertinent si la boutique est volontairement minimaliste et que les seuls besoins sont du cache objet pur. Toute boutique qui envisage à terme une queue de jobs, du rate limiting API ou des sessions partagées multi-serveurs gagne à partir directement sur Redis.

Quand Varnish a du sens (et quand il ne faut pas)

Varnish (ou NGINX cache full-page) est l’optimisation à plus fort levier sur PrestaShop : il sert les pages anonymes en quelques millisecondes au lieu de 400-800 ms. Mais Varnish n’est pas un game-changer dans toutes les configurations.

Cas où Varnish change tout

• Trafic majoritairement anonyme : visiteurs non connectés, pas de prix personnalisés par client, pas d’A/B test à clé serveur. Catalogue B2C grand public.
• Volume élevé concentré sur peu d’URLs : une homepage, 50 catégories, 500 fiches produit représentent 80 % du trafic. Le cache fait l’essentiel du travail.
• Pic saisonnier prévisible : Black Friday, soldes. Varnish absorbe le trafic sans saturer PHP-FPM.

Cas où Varnish est un piège

• Boutique B2B avec connexion obligatoire : chaque page est personnalisée (prix groupe client, multi-utilisateurs, devis en cours). Varnish ne sert que les pages publiques (rares) et la complexité dépasse le gain.
• Personnalisation côté serveur : recommandations IA par utilisateur, A/B testing serveur, prix dynamiques. Le cache full-page rend caduque toute la personnalisation.
• Trafic anonyme dispersé sur des milliers de longue-traîne : si chaque URL est visitée 1 fois par jour, le hit ratio reste faible et Varnish n’apporte rien.

L’alternative edge cache CDN

En 2026, Cloudflare Cache Rules, BunnyCDN Permacache, Fastly et autres edge caches font le travail de Varnish au niveau du CDN, sans serveur supplémentaire. Avantage : pas de couche à maintenir, distribution géographique, intégration WAF native. Inconvénient : la purge fine est moins flexible que Varnish, et le coût peut grimper sur les gros volumes. Pour 80 % des boutiques mid-market, l’edge cache CDN est devenu une alternative supérieure à un Varnish auto-hébergé.

Coût réel et ROI d’une stack de cache propre

Coût

• OPcache : 0 €. Activer et bien dimensionner.
• Redis : 0 € en local (même serveur que PHP-FPM) à 15-30 €/mois sur un VPS dédié (Hetzner CX11) ou Redis managé (Upstash, Redis Cloud) à partir de 10 €/mois.
• Varnish : 0 € open source, mais 1 à 3 jours d’installation et tuning par un sysadmin compétent. À budgéter en temps, pas en licence.
• Edge cache CDN : Cloudflare Pro 25 $/mois, BunnyCDN environ 1 $/Go transféré, Fastly à partir de 50 $/mois usage-based.
• Implémentation initiale : 2 à 5 jours de dev pour une boutique standard (configuration, tests, purge automatique sur webhook PrestaShop).

ROI mesuré

Sur des audits de boutiques PrestaShop 8 mid-market post-déploiement d’une stack de cache propre :

• TTFB passe de 600-800 ms à 80-150 ms en hit cache.
• LCP descend de 3,2 s à 1,4 s sur fiche produit anonyme.
• Taux de rebond mobile baisse de 12 à 18 % en moyenne.
• Conversion mobile augmente de 6 à 12 %.
• Budget de crawl Google double, ce qui se traduit en 4-8 semaines par +15 % d’URLs indexées.

Le coût d’opportunité de ne pas mettre en place de cache propre dépasse souvent 1 % de CA annuel. Une boutique à 1 M€/an perd typiquement 10 à 20 K€/an en performance dégradée.

Les pièges à éviter

1. Empiler des modules de cache sans cohérence

Beaucoup de boutiques accumulent : module officiel PrestaShop cache, module Redis tiers, module Varnish séparé, plugin CDN. Sans hiérarchie claire, les caches s’invalident mal entre eux et certains hits annulent les autres. Il faut une et une seule politique de cache documentée, avec un schéma clair de purge en cascade.

2. Mal gérer la purge sur événement

Quand un prix change, qu’un stock se met à jour, qu’un attribut produit est modifié, la page concernée doit être purgée. PrestaShop n’a pas de hook unifié — il faut câbler actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter et déclencher la purge correcte (Varnish PURGE, Redis DEL, CDN API). Sans ça, le visiteur voit un prix obsolète, ce qui peut tomber sous la directive Omnibus.

3. Cacher des pages personnalisées

Le panier, le compte client, le checkout et toute page contenant des données utilisateur ne doivent jamais entrer en cache full-page. La règle Varnish ou CDN doit explicitement exclure ces routes (/cart, /mon-compte, /commande, /identite). Erreur fréquente : une boutique qui cache tout par défaut affiche le panier d’un autre client. Incident grave et difficile à diagnostiquer après coup.

4. Ne pas tester sous charge

Un cache propre se valide sous charge. Un outil comme k6 ou Locust permet de simuler 500-1000 visiteurs simultanés et de mesurer le hit ratio, le TTFB sous charge, la stabilité PHP-FPM. Sans ce test, on découvre les problèmes en production un jour de pic — le pire moment pour corriger.

5. Oublier le multishop et la multi-currency

Un cache trop agressif sur une boutique multishop peut servir la même page HTML à toutes les boutiques, ou servir le prix EUR à un visiteur en GBP. La clé de cache doit inclure id_shop, id_lang, id_currency au minimum. Vérifier explicitement la clé de cache générée — c’est l’erreur silencieuse la plus coûteuse en perte de conversion.

La stack recommandée par défaut en 2026

Pour 80 % des boutiques PrestaShop 8 / 9 mid-market (CA 200 K€ à 5 M€/an) :

1. OPcache activé avec 256 Mo et opcache.validate_timestamps=0 en production.
2. Redis comme backend de cache objet PrestaShop (sessions, Smarty, métadonnées). Une instance suffit dans la plupart des cas.
3. Edge cache CDN (Cloudflare ou BunnyCDN) sur les pages catalogue et CMS publiques, avec exclusion explicite des routes utilisateur.
4. Cache navigateur agressif sur les ressources statiques (1 an), versionnées par hash via le système d’asset PrestaShop.
5. Pas de Varnish sauf cas spécifique de gros trafic homogène où le tuning et la maintenance se justifient.

Cette stack se déploie en 2 à 5 jours, coûte 10 à 30 € par mois en frais récurrents, et apporte un gain de performance bien supérieur à ce qu’on peut obtenir en optimisant le code applicatif. Avant toute optimisation back-end (refonte de modules, requêtes SQL), passer ces cinq points en revue reste la première étape rentable.