Table des matières :
- Soldes PrestaShop : la mécanique qui fait tomber une boutique
- Cache multi‑niveaux : cartographie utile (et ce que chaque niveau doit absorber)
- Reverse proxy (Varnish/Nginx) : maximiser le hit ratio sans casser panier/compte
- Cache objet (Redis/Memcached) : réduire la pression DB et stabiliser le checkout
- OPcache + PHP‑FPM : le niveau “non négociable” pour survivre aux pics
- CCC PrestaShop (Combine, Compress, Cache) : à utiliser comme un outil, pas comme une religion
- Validation en conditions de soldes : mesures, tests de charge, rollback
En période de soldes, PrestaShop se fait punir sur deux axes : le TTFB (temps serveur) et l’explosion du nombre de requêtes statiques (CSS/JS/images) par page. Le cache « à un seul niveau » (juste Smarty ou juste Varnish) ne tient pas longtemps : la charge se déplace simplement (CPU PHP, I/O disque, MySQL, réseau), et vous perdez le contrôle du hit ratio. Ce qui tient en production, c’est un cache multi‑niveaux cohérent + une stratégie CCC (Combine/Compress/Cache) pragmatique.
Dans cet article, les exemples et recommandations visent PrestaShop 8.1–9.1 (PS 9 = Symfony 6.4) et PHP 8.2/8.3. Les réglages de cache sont sensibles : testez en staging, instrumentez, puis déployez avec rollback. Si vous cherchez d’abord une vue d’ensemble des couches serveur (Varnish/Redis/Memcached/OPcache), le socle est déjà posé ici : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur.
Un point souvent sous‑estimé en e‑commerce (et particulièrement en France pendant les périodes réglementées de soldes) : le trafic ne monte pas seulement « en volume », il se déséquilibre. Vous avez davantage de visites sur quelques pages clés (home, catégories « Soldes », best‑sellers, pages produit remises), plus de rafraîchissements et de retours arrière, plus de robots comparateurs/affiliés — et des modules (tracking, recommandations, avis, paiement) qui ajoutent chacun leur part de requêtes et de cookies.
Soldes PrestaShop : la mécanique qui fait tomber une boutique
Le scénario classique : la home et les catégories « soldes » deviennent les pages les plus vues, et elles déclenchent une cascade (prix spécifiques, règles panier, facettes, images, blocs dynamiques, modules). Quand le cache est insuffisant, vous observez : CPU PHP‑FPM qui sature, latence MySQL qui grimpe, et file d’attente côté PHP‑FPM/Apache/Nginx. À partir de là, vous ne perdez pas seulement du confort : vous perdez des commandes.
Le piège PrestaShop, c’est que le cœur n’impose pas une architecture de cache robuste. PrestaShop peut fonctionner « correctement » sans reverse proxy, sans objet cache externe, avec CCC au hasard… jusqu’au jour où le trafic passe de 50 req/s à 300 req/s. En soldes, ce jour arrive. La bonne approche est de découpler : cache HTTP en amont pour absorber le volume, cache applicatif (objet) pour réduire le coût des calculs, et cache opcode pour rendre PHP viable.
Enfin, ne pas confondre « activer un cache » et « garantir un hit ratio ». Un reverse proxy mal configuré peut être pire que rien : si vous bypassez trop souvent (cookies, headers, query params), vous payez l’overhead sans bénéfice. Le sujet n’est pas “mettre Varnish”, c’est choisir précisément quoi cacher, combien de temps, avec quelles variations, et comment invalider.
Pour rendre ça concret, gardez une règle d’or en tête : pendant les soldes, votre objectif n’est pas de servir “la page parfaite” à la milliseconde près, c’est de servir une page rapide et correcte avec un checkout stable. Si une catégorie peut être servie avec 120 secondes de TTL au lieu d’un recalcul complet à chaque visite, vous venez de transformer une panne probable en simple divergence acceptable (surtout si vous affichez déjà une disponibilité « indicative » et que le stock réel est confirmé au panier/checkout).
Cache multi‑niveaux : cartographie utile (et ce que chaque niveau doit absorber)
Un cache multi‑niveaux efficace sur PrestaShop se pense en 4 couches :
1) Navigateur + CDN : absorbe le statique (images, CSS/JS, polices) et une partie du HTML si vous avez une stratégie edge (souvent limitée en e‑commerce à cause des variations).
2) Reverse proxy HTTP (Varnish, Nginx cache) : sert le HTML des pages non personnalisées et protège PHP/MySQL.
3) Cache applicatif / objet (Redis/Memcached) : stocke des résultats de calcul et réduit les allers‑retours DB.
4) OPcache : supprime le coût de compilation PHP à chaque requête.
Pourquoi cette séparation est importante : chaque couche a sa granularité et sa latence. Le navigateur/CDN vise des TTL longs et des clés simples (URL + headers). Le reverse proxy vise des TTL moyens et des règles de variation (cookies, device, langue). Le cache objet vise des TTL courts ou de l’invalidation fine (tags, clés fonctionnelles). OPcache n’est pas un cache de données : c’est un cache d’opcodes.
Référence utile, parce qu’elle résume bien l’enjeu côté reverse proxy : la doc officielle Varnish rappelle que « Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy » (varnish-cache.org). Traduction technique : c’est un composant conçu pour servir du HTTP vite, pas un “plugin PrestaShop”. À vous de le piloter avec des règles adaptées au comportement de votre boutique.
Pour cadrer rapidement « qui doit absorber quoi », cette table aide à éviter les confusions (et les doublons inutiles) :
| Niveau | Ce qu’il doit idéalement absorber | Indicateur à suivre | TTL typique en soldes (ordre de grandeur) |
|---|---|---|---|
| Navigateur/CDN | images, CSS/JS versionnés, polices | ratio cache hit CDN, bande passante origine | jours à 1 an (si versionné) |
| Reverse proxy | HTML non personnalisé (home, catégories, CMS, produits selon thème) | X-Cache HIT/MISS, hit ratio global |
30s à 15min |
| Cache objet | résultats de calculs / lectures répétées (config, règles, fragments) | latence p95, eviction rate, mémoire | secondes à minutes |
| OPcache | bytecode PHP | opcache_get_status, saturation mémoire |
“jusqu’au déploiement” |
L’intérêt de cette lecture : si votre HTML est majoritairement MISS (reverse proxy), mais que votre statique est bien servi (CDN), vous aurez une boutique qui “charge vite après le TTFB”… sauf que le TTFB restera mauvais, et c’est précisément ce qui s’écroule pendant les pics.
Reverse proxy (Varnish/Nginx) : maximiser le hit ratio sans casser panier/compte
Sur une boutique PrestaShop, vous ne cachez pas “tout le HTML”. Vous cachez surtout : home, catégories, listing marque/fournisseur, pages CMS, pages produit… tant que elles ne contiennent pas de fragments personnalisés dépendants du client (panier, compte, recommandations personnelles). Si votre thème ou des modules injectent des contenus dynamiques partout (mini‑panier, bannière “Bonjour Paul”), votre hit ratio s’effondre.
La stratégie robuste consiste à :
- Bypass explicite dès qu’un cookie critique est présent (ex.
PrestaShop-*de session), ou dès qu’on est sur des routes sensibles (panier, commande, compte). - Normaliser les variations : langue, devise, groupe client, mobile/desktop si vous servez des HTML différents.
- Fixer des TTL réalistes (ex. 60–300s sur catégories en soldes, 300–900s sur CMS) et prévoir une invalidation (purge par URL / BAN).
Sur PrestaShop en Docker, vous avez déjà une base exploitable pour valider le fonctionnement via en‑tête X-Cache et VCL : PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache. Pour aller plus loin sur des pages « quasi cacheables » malgré des zones dynamiques, l’approche fragments/ESI existe, mais elle augmente la complexité (et les risques de mismatch). Si vous devez absolument garder un mini‑panier dynamique sur des pages cacheées, lisez : Varnish Cache : configuration ESI pour optimiser le cache par fragments.
Points durs typiques en soldes :
- Paramètres d’URL : la navigation à facettes / tri / pagination explose les variantes d’URL et tue le cache. Il faut décider ce que vous cachez et ce que vous bloquez ou rate‑limit (voir aussi la logique de protection via Fail2ban quand les robots abusent) : PrestaShop sécurité : bloquer la navigation à facettes via fail2ban.
- Cookies inutiles : certains modules posent des cookies marketing qui forcent le bypass si votre VCL est naïf (variation sur
Cookie:complet). Nettoyez/filtrez côté Varnish : ne variez que sur l’essentiel. - Invalidation : si vous purgez “tout” à chaque update stock/prix, vous perdez l’intérêt du cache. En soldes, vous devez accepter un TTL court et une purge ciblée.
Deux ajouts très “rentables” pour le hit ratio (sans entrer dans une usine à gaz) :
- Normaliser les query params de tracking avant calcul de la clé cache (sinon vous cachez la même page 20 fois) :
utm_*,gclid,fbclid,msclkid, etc. Côté SEO et analytics, vous gardez les paramètres côté navigateur, mais côté cache vous évitez la fragmentation. - Limiter volontairement les variations : si vous servez la même page pour desktop et mobile (thème responsive), ne variez pas sur l’UA. Si votre devise ne change pas le contenu en listing (ou si la plupart de vos clients sont en EUR), vous pouvez décider de réduire la combinatoire (au prix d’une contrainte produit/marketing). Pendant soldes, la combinatoire “langue × devise × tri × facettes” peut devenir le tueur n°1.
Mini‑scénario (typique) : une boutique FR a une catégorie “-50%” très visitée. Entre ?page=, ?order=, et les facettes q=taille-..., vous passez de 1 URL à plusieurs milliers de variantes en quelques heures. Sans règle (normalisation + TTL + plafonnement), Varnish devient un “cache de MISS” et vous n’avez plus l’effet bouclier attendu.
Cache objet (Redis/Memcached) : réduire la pression DB et stabiliser le checkout
Varnish réduit le nombre de requêtes PHP, mais il ne règle pas le coût des requêtes PHP restantes (checkout, recherche, pages non cacheables). Là, c’est le cache objet qui fait la différence : données de configuration, calculs de prix, résultats d’assemblage de blocs, verrous (locks), etc. En pratique, Redis est souvent préféré car polyvalent et instrumentable.
Citation utile et factuelle : la documentation Redis définit Redis comme « an in‑memory data structure store, used as a database, cache, and message broker » (redis.io). C’est exactement ce qu’on exploite : un cache en RAM, avec TTL, eviction policy, et métriques. Mais attention : Redis mal dimensionné = eviction agressive = cache churn = latence instable.
Pour une mise en place propre côté PHP (extension, choix des bases, surveillance), référez‑vous à : Redis PHP : activer l’extension, choisir les bases et surveiller l’usage. Et en soldes, Redis sert aussi à éviter des effets de concurrence (oversell, double réservation) si vous implémentez des locks/transactions : Performance e‑commerce : prévenir la concurrence sur les stocks avec Redis.
Concrètement, vous cherchez deux gains :
- Réduire les hits MySQL sur des lectures répétitives (config, prix spécifiques, groupes, règles). Cela se mesure via
performance_schema, slow logs, et surtout la baisse de QPS DB à trafic égal. - Stabiliser les endpoints non cacheables (panier/commande) : moins de requêtes et moins de contention = moins de timeouts. Si vous voyez des erreurs DB intermittentes pendant les pics, le diagnostic infra est à traiter en parallèle : Erreurs base de données OVHcloud : diagnostic et solutions d’hébergement Web.
Quelques points pratiques (souvent oubliés) à valider avant soldes :
- Politique d’éviction : si Redis est utilisé comme cache, une politique de type LRU (selon votre stratégie) évite des “trous” brutaux, mais vous devez surtout éviter que Redis passe son temps à évincer parce que
maxmemoryest trop bas. - Isolation des usages : si vous utilisez Redis pour autre chose (sessions, queue, locks), séparez au minimum par bases/logique de clés, et suivez la volumétrie. Le pire timing, c’est découvrir en pic que vos sessions ont expulsé vos clés cache (ou l’inverse).
- Surveillance des symptômes : latence Redis qui monte, ratio keyspace hits/misses qui se dégrade, evictions qui explosent. Ces trois signaux suffisent souvent à expliquer un checkout “instable” même si MySQL ne semble pas saturé.
OPcache + PHP‑FPM : le niveau “non négociable” pour survivre aux pics
Le cache opcode n’est pas glamour, mais c’est souvent le premier multiplicateur de capacité. Le manuel PHP est clair : « OPcache improves PHP performance by storing precompiled script bytecode in shared memory » (php.net). En clair : sans OPcache, vous brûlez du CPU à recompiler du PHP à chaque requête — et en soldes, ça devient un incendie. Référence officielle (utile pour vérifier directives et valeurs) : https://www.php.net/manual/en/book.opcache.php
Sur PrestaShop 8/9, OPcache doit être activé en production, avec une mémoire suffisante et une politique de revalidation compatible avec vos déploiements. Sur hébergements cPanel, la vérification est documentée ici : OPcache PHP : activer et vérifier l’extension dans cPanel. Sur VPS/cloud, vous devez aussi aligner PHP‑FPM (pm.maxchildren, pm.maxrequests, timeouts) et surveiller les limites OS (open files, sockets) — surtout sur PrestaShop 9 : PrestaShop 9 : corriger l’erreur « too many open files ».
Points concrets à valider avant soldes :
opcache.memory_consumptiondimensionné (souvent 256–512MB sur un PrestaShop riche en modules),opcache.max_accelerated_filessuffisamment élevé.opcache.validate_timestampsetopcache.revalidate_freqcohérents avec votre pipeline de déploiement (si vous faites du blue/green ou des releases immuables, vous pouvez désactiver la validation timestamp et reset au déploiement).- Un warmup applicatif (hit sur pages clés après déploiement) pour remplir Varnish + caches internes et éviter le “cold start” en plein pic.
Pour éviter les réglages “au hasard”, vous pouvez partir d’un socle lisible (à adapter à votre infra et à la taille du codebase). Exemple de base (indicatif) :
; OPcache (exemple indicatif)
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=40000
opcache.validate_timestamps=0
opcache.jit=0
Pourquoi jit=0 ici : sur des stacks e‑commerce classiques, le gain du JIT n’est pas systématique, et le risque/temps de validation en période sensible n’en vaut pas toujours la peine. L’important est d’être prévisible.
Pour une approche benchmark/paramétrage reproductible PHP‑FPM/OPcache/MySQL, vous avez une base solide ici : Performance PrestaShop : benchmarks et optimisation PHP‑FPM, OPCache, MySQL.
CCC PrestaShop (Combine, Compress, Cache) : à utiliser comme un outil, pas comme une religion
Le CCC dans PrestaShop (Back‑office > Performances) est historiquement conçu pour : combiner des fichiers CSS/JS, les minifier, et exploiter un cache disque. Sur le papier c’est simple. Dans la vraie vie (HTTP/2, bundles modernes, modules qui injectent du JS à la volée), ça peut : casser l’ordre de chargement, générer des 404 sur assets, ou faire exploser les invalidations.
Avec HTTP/2 et HTTP/3, la combinaison “agressive” des fichiers n’est plus systématiquement gagnante : le coût de multiples requêtes est moins pénalisant, tandis que les gros bundles peuvent dégrader le LCP/INP si vous forcez trop de JS au chargement. Google rappelle dans sa doc CWV que le LCP mesure la vitesse d’affichage du contenu principal (web.dev). Traduction opérationnelle : votre CCC doit servir le LCP, pas juste réduire le nombre de fichiers.
Stratégie réaliste pour soldes :
- CSS : minifier, oui ; combiner, seulement si vous maîtrisez l’ordre et si vos modules n’injectent pas des styles conditionnels. Validez au minimum sur home/catégorie/produit/checkout.
- JS : évitez de combiner si vous avez déjà une pipeline moderne (Webpack/Vite via thème). Favorisez
deferquand possible et surveillez l’INP. - Cache des assets : mettez des headers
Cache-Control: public, max-age=31536000, immutablesur les fichiers versionnés (hash), et des TTL courts sur les fichiers non versionnés. Sans versionning, CCC crée des invalidations “à l’aveugle”.
Une limite du cœur PrestaShop : CCC n’est pas un bundler moderne et ne comprend pas toujours la logique de dépendances des modules. Si vous êtes sur un thème custom avec une vraie chaîne d’assets, considérez CCC comme un filet de sécurité, pas comme la source de vérité. Et si vous devez debug des régressions, repassez en mode non combiné pour isoler (puis remettez un par un).
Checklist rapide (très efficace avant soldes) pour éviter l’activation “à la loterie” :
- Vérifier qu’aucun module n’injecte la même librairie (jQuery, sliders, trackers) plusieurs fois : ce n’est pas “du cache”, c’est du poids inutile.
- Contrôler que vos fichiers CSS/JS ont un versionning (hash, ou query string stable). Sinon, vous serez obligé de réduire le TTL, et vous perdrez une partie des gains CDN/navigateur.
- Surveiller 2 symptômes après activation CCC : hausse des erreurs JS (console) et baisse du taux de cache HIT sur le statique (si le versionning change trop souvent ou si des fichiers deviennent non cacheables).
Validation en conditions de soldes : mesures, tests de charge, rollback
Optimiser le cache “au feeling” ne tient pas. Vous devez instrumenter : hit ratio Varnish, distribution des codes HTTP, TTFB p95/p99, saturation PHP‑FPM, latence MySQL, et taux d’erreurs applicatives. Un runbook soldes doit lister : quoi surveiller, quel seuil déclenche une action, et quelle action est safe. Pour la méthode orientée soldes (monitoring + tests + runbooks), basez‑vous sur : PrestaShop performance : monitoring, tests de charge et runbooks soldes.
Côté métriques web, reliez vos actions cache à des résultats : baisse du TTFB, amélioration LCP, stabilité INP. Deux lectures utiles pour cadrer : TTFB PrestaShop : réduire le Time To First Byte sous 200 ms et Core Web Vitals : actions concrètes pour améliorer LCP, INP et CLS. Pour mesurer proprement (sans illusions), la partie outillage navigateur est ici : DevTools : méthodes professionnelles pour mesurer et optimiser les performances web.
Un format simple qui marche en prod : associer un symptôme à une métrique et à une action « sans danger ». Exemple (à adapter) :
| Symptôme | Signal | Action immédiate (safe) | Action de fond |
|---|---|---|---|
| TTFB explose sur catégories | X-Cache majoritairement MISS + PHP‑FPM en file |
augmenter TTL catégories + normaliser params + bypass cookies inutiles | revoir variations, ESI si nécessaire |
| Checkout lent / erreurs intermittentes | latence DB p95 + timeouts | réduire charge via cache HTML + limiter bots | optimiser requêtes, cache objet, dimensionnement DB |
| Pic 404 sur assets | logs Nginx/Apache | désactiver combinaison CCC, purger statique | corriger ordre/chemins, versionning |
| Serveur “à genoux” après purge globale | baisse brutale HIT ratio | warmup ciblé (home/catégories top) | stratégie de purge ciblée / ban |
Enfin, prévoyez le rollback, parce que CCC et Varnish peuvent casser des parcours critiques. Un plan minimal :
- un switch “bypass cache HTML” (toggle VCL / header / rule) activable sans redéployer ;
- une bascule CCC désactivable rapidement (et cache vidé côté PrestaShop) ;
- un mécanisme de purge ciblée et une purge totale d’urgence (en assumant l’impact).
Si vous avez besoin d’un tableau de bord et de seuils actionnables (pas juste des graphes), vous pouvez vous appuyer sur : Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes. C’est ce cadre qui permet de transformer « optimiser le cache multi‑niveaux et CCC » en résultat concret pendant les soldes : des pages servies en cache, un checkout stable, et une production qui ne part pas en vrille au premier pic.