Aller au contenu
EdgeServers
Blog

La stack de cache WordPress qui survit vraiment au Black Friday

12 mai 2026 · 2 min de lecture · par Sudhanshu K.

Il y a une question à laquelle tout site WordPress managé finit par faire face : qu'est-ce qui explose lors d'un pic de trafic de 50× ? La réponse courte est généralement la base de données — non pas parce que MySQL est mauvais, mais parce que chaque couche de cache entre le visiteur et la base de données est mal configurée, manquante, ou fait le mauvais travail.

Les quatre caches qui comptent

Un site WordPress en production a besoin de quatre couches de cache, et l'ordre compte :

  1. Cache edge — Cloudflare, BunnyCDN, CloudFront. Attrape le trafic anonyme au bord du réseau.
  2. Cache de page — WP Rocket, W3 Total Cache, LiteSpeed Cache. Sert du HTML complet depuis le disque ou la mémoire pour les hits anonymes répétés.
  3. Cache d'objets — Redis ou Memcached, via Object Cache Pro ou W3TC. Évite l'aller-retour vers MySQL pour des choses comme get_option(), get_transient(), et les lectures de session WooCommerce.
  4. Cache d'opcode — PHP OPcache, configuré avec opcache.validate_timestamps=0 en production. Évite de re-compiler les fichiers PHP à chaque requête.

Si vous omettez le cache d'objets, MySQL devient le goulot d'étranglement dès que votre cache edge manque. Si vous omettez le cache d'opcode, votre plancher CPU est 2-3× plus élevé qu'il ne devrait l'être. Si vous omettez le cache edge, vous paierez pour chaque bot qui indexera votre site.

Ce que nous configurons réellement

Pour un site WooCommerce traitant 100 000 commandes mensuelles, nous déployons typiquement :

  • Cloudflare en façade, avec un tuning du cache HTML par route (pages catalogue agressives, contournement panier/checkout par cookie)
  • WP Rocket pour le cache de page, avec WP_CACHE activé et le cache disque vivant sur un volume SSD
  • Redis avec Object Cache Pro pour le cache d'objets (le plugin gratuit redis-cache fonctionne mais Pro est plus rapide sous contention)
  • OPcache avec 256 Mo alloués et opcache_reset() déclenché à chaque déploiement
  • Une instance Redis séparée pour le stockage des sessions WooCommerce afin que le checkout ne se batte pas avec les autres lectures

L'article complet sur Medium couvre les fichiers de config réels, le hook de déploiement qui réinitialise chaque couche, et les dashboards de monitoring que nous mettons par-dessus.

Article complet disponible

Lire l'article complet