Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN

Table des matières :

1. Empiler le cache PrestaShop en 2026 : du bytecode au edge
2. OPcache (PHP 8.3/8.4) : réglages, invalidation et préchargement
3. Redis : cache applicatif, verrous et sessions (sans tuer MySQL)
4. Varnish devant PrestaShop : FPC réaliste, cookies, purge et ESI
5. CDN en 2026 : statique + edge cache, headers et sécurité
6. Mesurer, monitorer, itérer : KPI, tests de charge et anti-patterns

Empiler le cache PrestaShop en 2026 : du bytecode au edge

En 2026, « cache PrestaShop » ne veut rien dire si vous ne précisez pas la couche. Sur une boutique PrestaShop 9.x (Symfony 6.4) en PHP 8.3/8.4, vous avez au minimum : cache opcode (OPcache), cache applicatif (Symfony Cache + legacy Cache), cache template (Smarty), cache HTTP (reverse proxy type Varnish) et cache edge (CDN). Chaque couche vise une latence différente : CPU PHP, I/O MySQL, RTT réseau, ou saturation du pool PHP-FPM.

Le cœur PrestaShop reste très dynamique : panier, prix par groupe, stock temps réel, cookies de tracking, variations multiboutique/multi-devise, etc. Le piège classique : « on met Varnish et tout va vite ». Non. Sans stratégie de variation (cookies, headers Vary), de TTL et surtout d’invalidation, vous basculez soit vers un cache quasi-inutile (hit ratio faible), soit vers un cache dangereux (fuite de contenu personnalisé). Pour le diagnostic TTFB et l’identification des goulots (bots, PHP-FPM, DB), gardez une méthode instrumentée plutôt que d’empiler les briques à l’aveugle : voir PrestaShop lent : diagnostic TTFB, bots et optimisation serveur.

Le bon modèle mental est un pipeline de cache :

• OPcache réduit le coût “compiler + optimiser” du PHP.
• Redis réduit les allers-retours vers MySQL pour des données dérivées (config, hooks, fragments, locks), et peut aussi absorber sessions/queues.
• Varnish fait du Full Page Cache (FPC) sur ce qui est réellement cachable (catégories, CMS, pages produit sous conditions), et laisse passer le reste.
• Le CDN cache le statique (assets, images) et, si vous assumez une approche “edge”, peut aussi faire du cache HTML avec règles strictes.

Pour éviter le flou (et améliorer le SEO on-page autour de requêtes comme cache PrestaShop, Varnish PrestaShop, Redis PrestaShop, OPcache PHP-FPM), gardez une cartographie simple des responsabilités :

Couche	Ce que ça accélère	Ce que ça ne doit pas faire	Signal à monitorer
OPcache	CPU PHP (bytecode), cold start après reload	“Cacher” des données métier (prix/stock)	opcache_hit_rate, fragmentation, oom_restarts
Redis	données dérivées, sessions, locks	masquer des requêtes SQL non indexées	evictions, latence, hit rate, used_memory
Varnish	HTML anonymes, absorption de pics	servir du contenu personnalisé (compte/panier)	HIT/MISS/BYPASS, beresp.ttl, grace
CDN	statique, réduction RTT/bande passante	cacher HTML sans règles strictes	hit ratio edge, bande passante origin, purge time

L’objectif opérationnel est mesurable : faire chuter le TTFB médian (p50) côté anonymes, augmenter le taux de HIT (Varnish/CDN), et stabiliser la latence p95/p99 sous charge. Une boutique qui passe d’un TTFB p50 de 600–900 ms à 120–250 ms sur les pages cachables n’est pas rare dès que l’invalidation est propre et que le pool PHP-FPM arrête de “recompiler” en boucle.

Dernier point “terrain” (GEO) : la valeur d’un CDN ou d’un reverse proxy se lit aussi à la distance réelle client ↔ serveur. Si votre clientèle est majoritairement en France/Belgique/Suisse et que l’origine est hébergée loin (ou dans une région cloud non optimale), vous payez en RTT et en variabilité. À l’inverse, un CDN bien configuré amortit la géographie (PoP proches) à condition que vos headers de cache soient corrects et que les pages réellement cachables soient identifiées.

OPcache (PHP 8.3/8.4) : réglages, invalidation et préchargement

OPcache est la base, parce que sans lui vous payez le coût de compilation à chaque worker et vous multipliez les IO disque. La doc PHP résume correctement l’enjeu : « The OPcache extension improves PHP performance by storing precompiled script bytecode in shared memory » (PHP Manual, OPcache) : PHP Manual — OPcache. Dans un stack PrestaShop, OPcache impacte surtout les temps CPU PHP (front) et la réactivité du back-office (beaucoup de classes/héritages).

En production, la décision structurante est comment vous invalidez. Si vous déployez par symlink (releases immuables), vous pouvez désactiver la vérification des timestamps et vous appuyer sur un opcache_reset() lors du switch de release (ou redémarrage PHP-FPM). Si vous déployez “in-place” (mutualisé, SFTP), vous devez laisser opcache.validate_timestamps=1 et accepter un léger coût de check. Dans les deux cas, fixez opcache.memory_consumption en fonction du code + modules + vendor Symfony ; trop bas = fragmentation, eviction, oscillation.

Exemple de base (à adapter, PHP-FPM, PrestaShop 9.2, Debian/Ubuntu), dans php.ini ou un fichier conf.d/10-opcache.ini :

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.jit=0

Trois points pratiques souvent négligés :

1) opcache.max_accelerated_files : avec Symfony + vendor, 10k est trop faible. 100k évite les éjections “silencieuses”.

2) opcache.save_comments=1 : indispensable pour certains usages d’annotations/attributs et de metadata ; le mettre à 0 casse des comportements.

3) JIT : pour du PHP “framework + IO + DB”, le JIT apporte rarement un gain stable et peut dégrader la prédictibilité ; le laisser à 0 est généralement plus rationnel.

Deux contrôles rapides qui évitent les “réglages à l’aveugle” :

• Après déploiement, vérifiez que le cache n’est pas “plein” : si opcache.memory_consumption est trop faible, vous verrez des redémarrages/évictions et une dégradation aléatoire.
• Surveillez la fragmentation : une fragmentation élevée + une mémoire limite = oscillations de performance (TTFB irrégulier) au lieu d’un gain net.

Si vous voulez aller plus loin, regardez le preloading (PHP 7.4+) pour charger à froid un ensemble de classes (framework) au démarrage de PHP-FPM. Ça peut réduire les pics de latence après reload, mais augmente le coût mémoire et complexifie le déploiement (il faut régénérer la liste à chaque release). Dans PrestaShop, le preloading a surtout du sens si vous faites des redémarrages fréquents (autoscaling, rolling deploy) et si vous cherchez à lisser les “premières requêtes” après reload.

Checklist déploiement “OPcache propre” (très concrète) :

• Releases immuables + symlink → validate_timestamps=0 + reload PHP-FPM au cutover.
• Déploiement in-place → validate_timestamps=1 + revalidate_freq bas (souvent 0 ou 1) selon contrainte.
• Ne jamais confondre “purge applicative” et “invalidation OPcache” : OPcache ne sait rien de vos prix/stock.
• En environnement multi-serveurs, synchronisez la stratégie (sinon vous aurez un front “chaud” et un front “froid” au hasard d’un load balancer).

Pour une approche plus globale (Nginx + PHP-FPM + cache + opcache), vous avez une base utile dans Symfony 7 : déploiement PHP-FPM Nginx, cache et opcache, transposable côté PrestaShop (mêmes mécaniques runtime).

Redis : cache applicatif, verrous et sessions (sans tuer MySQL)

Redis n’est pas “un cache” au sens strict : c’est un store mémoire multi-structures avec persistance optionnelle. La définition officielle est stable : « Redis is an in-memory data structure store, used as a database, cache, and message broker » (redis.io) : Redis documentation. Dans PrestaShop, Redis prend de la valeur dès que vous avez : beaucoup de trafic anonyme, des pages listant des produits (requêtes et calculs répétitifs), des modules qui font du “read heavy”, ou un multi-front (plusieurs pods/VM) où un cache local serait incohérent.

Côté PrestaShop, il faut distinguer :

• Cache applicatif : certains modules et le cœur (selon versions) peuvent utiliser un backend type Redis via Symfony Cache (adapters) ou via le système legacy. Le bénéfice est réel si vous cachez des résultats de calcul (ex. mapping catégories/IDs, règles de prix pré-calculées, fragments HTML non personnalisés) avec TTL courts.
• Sessions : sortir les sessions du disque (ou de la DB) vers Redis améliore la latence et la stabilité (moins de locks filesystem). Attention : si vous activez des sessions Redis, vous devez penser haute dispo (sentinel/cluster) et politique d’éviction.
• Locks : les verrous (import, synchronisation ERP, jobs) sont plus fiables dans Redis que dans la DB si vous gérez les timeouts correctement.

Le point dur : Redis doit être dimensionné et gouverné. Ne mettez pas maxmemory-policy allkeys-lru sans comprendre l’impact : vous pouvez éjecter des clés critiques (sessions) sous pression mémoire. Si vous mixez sessions + cache applicatif, séparez au minimum par bases logiques (db 0 / db 1) ou, mieux, par instances (Redis dédié sessions, Redis dédié cache) pour maîtriser l’éviction.

Mini-scenario (typique e-commerce) : pendant une campagne Meta/Google Ads, les pages catégories et les pages marque reçoivent une rafale de trafic anonyme. Sans cache applicatif, PrestaShop recalculera en boucle la même logique (règles de prix, filtres, disponibilités, modules de cross-selling) et la DB absorbera mal les “reads” répétitifs. Avec Redis (et des TTL courts sur les données dérivées), vous réduisez la pression DB et vous stabilisez le p95, ce qui se voit immédiatement sur les pics d’abandon quand le site “saccade”.

Exemple minimal (Linux) pour limiter les dégâts :

# redis.conf
maxmemory 2gb
maxmemory-policy volatile-lru
appendonly yes
appendfsync everysec
protected-mode yes
bind 127.0.0.1 ::1

• volatile-lru implique que seules les clés avec TTL sont éligibles à l’éviction : bon défaut pour du cache applicatif, mauvais si vos sessions n’ont pas de TTL.
• AOF (appendonly) + everysec est un compromis ; si Redis n’est “que cache”, vous pouvez couper la persistance et accepter la perte au reboot.

Deux recommandations “qualité de service” qui évitent les incidents silencieux :

• Donnez un TTL explicite à ce qui est cache (config dérivée, fragments, résultats calculés). Sans TTL, vous transformez Redis en “pseudo base” et vous finirez par saturer la mémoire.
• Définissez une règle d’éviction cohérente avec le métier : les sessions sont sensibles (risque de déconnexion) ; les fragments HTML le sont moins (on peut régénérer).

Sur un dédié ou VPS, la stack “Nginx + PHP-FPM + MariaDB + Redis” est détaillée dans Serveur dédié PrestaShop : config Nginx PHP-FPM MariaDB Redis.

Dernier rappel : Redis est une surface de sécurité. Si vous l’exposez réseau, vous méritez l’incident. Bind strict (ou socket UNIX), firewall, ACL/mot de passe, et surtout pas de port ouvert “parce que le dev veut tester”. La checklist de durcissement DB/infra de votre côté s’aligne avec les logiques décrites dans Sécurité MySQL : pare-feu, TLS, privilèges minimaux et audit (même philosophie : réduire l’exposition, contrôler les flux, auditer).

Varnish devant PrestaShop : FPC réaliste, cookies, purge et ESI

Varnish n’est pas “un accélérateur magique”, c’est un cache HTTP très agressif… à condition de lui donner des règles. La définition officielle est sans ambiguïté : « Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy » (Varnish documentation) : Varnish documentation. Dans PrestaShop, il est pertinent surtout pour les pages majoritairement identiques entre visiteurs (catégories, CMS, pages marque) et pour absorber les pics (soldes, campagnes).

Le nerf de la guerre est la variabilité par cookie. PrestaShop pose une quantité de cookies (session, panier, consent, tracking). Si vous faites varier le cache sur tous les cookies, vous tuez le hit ratio. Si vous ignorez les cookies, vous risquez de servir un header “Connecté” à tout le monde, voire un panier d’un autre. Le modèle “safe” est :

• Cacher uniquement pour visiteurs non authentifiés (pas de cookie client), panier vide (ou cookie panier absent), et sur un subset d’URLs.
• Normaliser/supprimer les cookies non fonctionnels du point de vue du rendu (ex. certains cookies analytics) dans la clé de cache.
• Forcer des TTL courts au début (30–120 s) puis ajuster selon invalidation.

Extrait VCL simplifié (à adapter, ne pas copier-coller en prod sans tester) :

sub vcl_recv {
  if (req.method != "GET" && req.method != "HEAD") {
    return (pass);
  }

  # Bypass pour back-office
  if (req.url ~ "^/admin") {
    return (pass);
  }

  # Bypass si cookie client (auth) ou panier
  if (req.http.Cookie ~ "(PrestaShop-.*=|ps_customer|ps_cart)") {
    return (pass);
  }

  # Nettoyage cookies bruit (ex. analytics)
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\\s*)(_ga|_gid|_fbp)=[^;]*", "");
  set req.http.Cookie = regsuball(req.http.Cookie, ";\\s*;", ";");
  if (req.http.Cookie ~ "^\\s*$") { unset req.http.Cookie; }
}

sub vcl_backend_response {
  if (bereq.url ~ "^/" ) {
    set beresp.ttl = 120s;
    set beresp.grace = 30s;
  }
}

Dans la pratique, vous gagnez beaucoup en fiabilité en ajoutant (au choix, selon votre site) :

• Normalisation des query strings (typiquement utm_*, gclid, paramètres de tracking) : si vous ne les ignorez pas, vous explosez le nombre d’objets en cache pour une même page SEO.
• BYPASS explicite sur des routes à forte personnalisation : recherche, compte client, panier, checkout, pages avec recommandation “personnelle”, endpoints AJAX.

L’invalidation est l’autre moitié du système. Sans purge/BAN, vous allez augmenter les TTL et finir avec un site qui affiche du stock/prix “en retard”. Vous avez trois stratégies, par ordre de maturité :

1) TTL courts + acceptation de la staleness (simple, peu coûteux, mais limité). 2) Purge par URL (hook PrestaShop “product update” → purge /produit-x, /categorie-y), faisable mais vite incomplet. 3) Tags (Surrogate-Key) + purge par clé (Fastly-like) : puissant, mais dépend du proxy/CDN et nécessite un marquage cohérent.

Ce qui marche bien sur un catalogue “vivant” (prix/stock qui bougent souvent) : TTL raisonnables + purge ciblée + grace. La grace (déjà illustrée dans le VCL) permet à Varnish de servir temporairement une version “un peu vieille” si l’origine est lente/indisponible, au lieu de laisser la file d’attente saturer PHP-FPM (effet “thundering herd”).

Côté PrestaShop, prévoyez un module ou un petit plugin qui écoute les hooks pertinents (mise à jour produit, prix spécifiques, stock, CMS) et déclenche une purge authentifiée sur Varnish. Ne faites jamais une purge ouverte à tout internet. Pour les risques de compatibilité (overrides, modules) et l’impact d’une migration sur ce type d’architecture, la checklist d’audit vaut lecture : Migration PrestaShop : checklist d’audit thème, modules, hooks et overrides.

Enfin, ESI (Edge Side Includes) est tentant sur le papier (“je cache la page et je rafraîchis juste un mini-bloc”), mais PrestaShop n’est pas nativement conçu comme un site ESI-first : vous devez cadrer exactement quels fragments sont “safe”, et accepter la complexité (debug, invalidation, compat modules). Sur beaucoup de boutiques, une stratégie FPC “anonymes uniquement” + bypass net sur les zones sensibles donne un meilleur ratio effort/gain.

CDN en 2026 : statique + edge cache, headers et sécurité

Un CDN, dans une stratégie “cache PrestaShop 2026”, sert d’abord à retirer du trafic au serveur d’origine : images, CSS/JS, polices, fichiers média. Sur ces assets, vous devez viser un Cache-Control: public, max-age=31536000, immutable avec fingerprinting (hash dans le nom de fichier). Sans fingerprinting, vous êtes obligé de réduire max-age, donc vous payez en bande passante et en latence.

Point concret : si votre thème ou vos modules régénèrent des URLs d’assets “stables” (sans hash) à chaque déploiement, vous vous condamnez à purger souvent au CDN… et donc à perdre l’intérêt d’un max-age long. À l’inverse, des bundles stables et versionnés (même en refonte progressive) améliorent immédiatement le hit ratio edge.

Si votre thème est en refonte, limiter le JS inutile et stabiliser les bundles (donc le cache) est un gain direct : voir Thème PrestaShop : passer à Hummingbird sans jQuery, focus accessibilité et CSS moderne : remplacer JavaScript pour interactions UI et performance.

Pour les pages HTML, le “CDN full-page cache” est possible mais doit être traité comme un reverse proxy (mêmes problèmes que Varnish, en pire si vous ne maîtrisez pas l’invalidation). Les fournisseurs modernes exposent des règles conditionnelles (cookies, chemins, querystring) et parfois des fonctions edge. Si vous cherchez un comparatif orienté capacités (HTTP/3, purge, WAF, règles, image optimization), vous avez une base : CDN : comparatif Cloudflare, Fastly, Akamai, CloudFront, Bunny.net, KeyCDN et CDN 2026 : critères techniques pour choisir le meilleur fournisseur.

Les headers HTTP sont votre contrat de cache. MDN rappelle un point simple mais fondamental : « The Cache-Control HTTP header holds directives (instructions) for caching in both requests and responses » (MDN Web Docs) : MDN — Cache-Control. Concrètement :

• Cache-Control: no-store pour pages sensibles (compte, checkout, admin).
• Cache-Control: private si une réponse varie par utilisateur (et que vous ne voulez pas qu’un proxy la garde).
• Vary uniquement sur ce qui est nécessaire (souvent Accept-Encoding, parfois Accept-Language si vous servez réellement du contenu différent).

Deux directives souvent utiles quand vous avez Varnish/CDN (cache partagé) :

• s-maxage : vous permet de donner un TTL “proxy/CDN” distinct du TTL navigateur.
• stale-while-revalidate / stale-if-error : utiles pour lisser la charge et améliorer la résilience (à manier avec prudence sur les contenus prix/stock).

Enfin, le CDN devient aussi une brique de sécurité : TLS, WAF, rate limiting, bot management. C’est utile, mais ça peut masquer des problèmes applicatifs (ex. endpoints non authentifiés) au lieu de les corriger. Pour une approche systémique (SBOM, WAF, CI/CD), vous pouvez croiser avec PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.

GEO (sans sur-promesse) : si votre boutique vend principalement en Europe, pensez aussi “gouvernance” (localisation des logs, contrat de sous-traitance, règles de conservation) et pas uniquement “latence”. Le CDN et/ou ses options de sécurité (WAF, bot management) peuvent avoir un impact sur la chaîne de données (journaux, IP, empreintes), ce qui doit rester cohérent avec votre cadre RGPD et vos politiques internes.

Mesurer, monitorer, itérer : KPI, tests de charge et anti-patterns

Une stratégie cache se pilote au compteur, sinon vous “optimisez” à l’intuition. KPI minimaux : TTFB p50/p95 (anonymes vs connectés), taux de HIT Varnish/CDN, nombre de requêtes PHP-FPM/s, latence DB (slow queries), et métriques Redis (hit rate, evictions, used_memory, ops/s). Sur Varnish : varnishstat (HIT/MISS/BYPASS), sur Redis : INFO stats, sur PHP : opcache_get_status() (fragmentation, memory).

Pour donner un cadre actionnable, vous pouvez vous fixer des cibles de progression (à adapter à votre secteur, modules et hébergement) :

KPI	Avant (souvent vu)	Après (cible réaliste sur pages cachables)
TTFB p50 (anonymes)	600–900 ms	120–250 ms
HIT ratio Varnish (anonymes, pages FPC)	< 20%	60–90%
Origin requests CDN (assets)	élevé	fortement réduit
Redis evictions	non surveillées	0 (ou expliquées)

Côté expérience utilisateur et SEO technique, ne vous limitez pas au TTFB : les signaux “terrain” s’évaluent aussi sur la stabilité et la disponibilité perçue. La documentation Google sur les Core Web Vitals donne un cadre utile pour relier performance et UX (sans confondre métriques navigateur et métriques serveur) : Google — Core Web Vitals.

Le monitoring doit aussi inclure la cohérence fonctionnelle. Un cache qui “marche” mais sert des prix erronés sur une devise, ou qui casse les promotions par groupe, est un incident. Automatisez des checks : pages produit (prix affiché vs API), stock (disponible vs non), panier (non caché), login (jamais caché). Sur une infra outillée, vous pouvez brancher des collecteurs type Netdata/Prometheus ; pour Netdata, une base de configuration est dans Netdata : activer et configurer les collectors pour monitoring temps réel.

Un processus d’itération simple (et efficace) :

1) Isoler une liste courte d’URLs candidates au FPC (catégories, CMS, marques). 2) Lancer Varnish en mode conservateur (bypass large, TTL courts), puis mesurer HIT/MISS/BYPASS. 3) Réduire la variabilité (cookies inutiles, query strings de tracking) sans toucher aux pages sensibles. 4) Ajouter la purge ciblée (produit, catégorie, CMS) et augmenter progressivement les TTL. 5) Valider par tests fonctionnels automatisés (prix/stock/panier/login) avant de “déverrouiller” davantage.

Anti-patterns qu’on voit encore trop sur PrestaShop :

• Activer tous les caches PrestaShop + Varnish + CDN sans gouvernance : vous empilez de la staleness, puis vous “purgez tout” en permanence → le cache ne sert plus.
• Mettre Redis en “cache miracle” sans regarder la DB : si vos requêtes sont non indexées, Redis ne sauvera pas votre MySQL. Pour la partie SQL, travaillez avec les logs et les index : PrestaShop MySQL : analyser slow query log et optimiser index.
• Cacher des pages personnalisées (compte, checkout, pages avec recommandation utilisateur) : c’est une fuite de données en puissance.
• Purger “tout le site” à chaque micro-changement (stock, prix, CMS) : vous revenez au mode “sans cache” pendant les périodes critiques (soldes, campagnes).

Quand vous itérez proprement, vous obtenez une architecture robuste : OPcache stabilise le CPU, Redis réduit la pression applicative, Varnish absorbe la majorité du trafic anonyme, le CDN sert le statique et amortit le réseau. Pour les réglages côté PrestaShop (Smarty, CCC, cache natif), gardez une base de référence, mais adaptez-la à votre stack (Nginx/Varnish/CDN) : Optimisation PrestaShop : nettoyer la base et configurer le cache natif et PrestaShop : optimiser performance via cache Smarty, CCC et CDN.