16mn de lecture
Pour accélérer un site en 2026, activez la mise en cache à tous les niveaux: OPcache côté PHP, cache d’objets Redis, cache HTTP via proxy/CDN et directives navigateur. Voici comment choisir et déployer, avec gains mesurables.
Qu’est-ce que la mise en cache moderne et pourquoi c’est crucial en 2026 ?
La mise en cache est l’art de servir plus vite des contenus en évitant des calculs inutiles. En 2026, elle se décline en cinq couches complémentaires: bytecode PHP (OPcache), cache d’objets (Redis/Memcached), cache de pages (Nginx microcaching/Varnish), cache en périphérie (CDN) et cache navigateur. Empiler intelligemment ces couches divise la consommation CPU et améliore TTFB, LCP et la stabilité sous charge.
Important: XCache, autrefois populaire, est désormais obsolète. À partir de PHP 5.5 puis de PHP 7/8, OPcache est intégré et maintenu officiellement. Passer d’XCache à OPcache supprime un risque d’incompatibilité, tout en offrant de meilleures optimisations (préchargement, JIT) et un suivi actif de sécurité.
Quels gains attendre? Dans des configurations réalistes: -30 à -60% de temps CPU sur les requêtes PHP avec OPcache, -20 à -50% de TTFB via un cache HTTP, et jusqu’à -70% de bande passante au niveau CDN. Pour l’utilisateur, cela se traduit souvent par 30 à 60% de vitesse perçue en plus sur WordPress, e-commerce ou sites d’actualités.
Les 5 couches, en bref
- OPcache (bytecode): compile et met en mémoire le code PHP. Il supprime la recompilation à chaque requête.
- Cache d’objets (Redis/Memcached): retient en RAM les résultats de requêtes SQL/objets transitoires (idéal pour WordPress, CMS, frameworks).
- Cache de page/reverse proxy (Nginx microcaching/Varnish): sert des pages HTML prêtes pour les visiteurs non connectés.
- CDN/edge: apporte les contenus près des utilisateurs, réduit la latence et absorbe les pics.
- Navigateur: directives Cache-Control/ETag pour assets (images, CSS, JS) et police/vidéo.
OPcache, Redis, Varnish, CDN: quelles combinaisons pour un site jusqu’à 60% plus rapide ?
Il n’existe pas une pile unique gagnante, mais des combinaisons optimisées selon votre usage. Voici des scénarios éprouvés, avec des ordres de grandeur de gains et des points de vigilance pour guider votre choix.
Scénarios types par stack
- Blog/actualités sous WordPress: OPcache + cache de page (Nginx microcaching 60–120 s) + CDN pour images. Gains typiques: -40% TTFB sur pages consultées en anonyme, ratio hit >90% sur assets. Attention aux cookies qui bypassent le cache.
- E-commerce (WooCommerce/PrestaShop): OPcache + Redis (cache d’objets) + cache de page sélectif (exclure panier/compte/checkout) + CDN. Gains: -25–40% TTFB sur catalogue, -20–35% CPU. Vérifier l’invalidation au changement de stock/prix.
- App web dynamique (API/SPA): OPcache + Redis (sessions/objets) + CDN pour assets + cache API de courte durée (stale-while-revalidate 10–30 s). Gains: -30% latence p95, meilleure résilience aux pics.
- Headless/SSR: OPcache + microcaching côté edge/CDN (1–10 s) + pré-rendu. Gains: pages quasi instantanées sous charge, mais invalider proprement lors des publications.
Repères de performance à viser
- TTFB: <200 ms (réponse servie depuis cache HTTP ou edge), <600 ms à froid.
- LCP: ≤2,5 s sur mobile 4G médiane pour pages clés (produits, articles, accueil).
- Hit ratio reverse proxy: ≥85% sur statique; 60–80% sur pages publiques.
- CPU serveur: baisse de 30–50% après activation OPcache + cache d’objets bien dimensionnés.
Implémentation pas à pas sur VPS/serveur: check-list prête à l’emploi
Cette feuille de route couvre l’essentiel, du système à l’application. Adaptez les tailles mémoire à votre trafic et surveillez l’effet réel via vos métriques.
1) Base système et runtime
- Mettez à jour l’OS (kernel, OpenSSL, cURL) et PHP-FPM 8.2/8.3 pour bénéficier d’OPcache et des optimisations récentes. Voir: Mettez à jour votre OS VPS avec Debian 13 et Ubuntu 24.04.
- Activez HTTP/2 ou HTTP/3, TLS 1.3, Brotli; servez les images en WebP/AVIF.
- Vérifiez PHP-FPM: pm = dynamic, pm.max_children dimensionné selon RAM/CPU/charge (ex.: 2–4 fois le nombre de cœurs, à affiner en production).
2) OPcache (PHP 8.x)
- Activer: opcache.enable=1, opcache.enable_cli=0 (1 si vous avez des CLI lourdes).
- Mémoire: opcache.memory_consumption=128–256M; opcache.interned_strings_buffer=16–32.
- Index: opcache.max_accelerated_files=10000–40000 (selon le nombre de fichiers PHP).
- Validation: en production, opcache.validate_timestamps=0 et déploiement avec vidage contrôlé (restart FPM ou reset OPCache). En staging, =1 avec opcache.revalidate_freq=2–10.
- Préchargement (si applicable): opcache.preload et opcache.preload_user pour frameworks lourds. Mesurer le bénéfice réel avant généralisation.
- JIT: utile pour workloads spécifiques CPU-bound; neutre ou négatif sur WordPress classique. Tester avant d’activer en production.
3) Cache d’objets (Redis)
- Installation: redis-server local avec socket Unix (plus rapide que TCP) si même hôte; sinon TCP sécurisé.
- Politique mémoire: maxmemory 256–1024M et maxmemory-policy allkeys-lru pour un cache strict.
- WordPress/CMS: activer un plugin de cache d’objets Redis; exclure les objets fortement volatils si nécessaire (sessions, paniers en cours).
- Monitoring: surveiller hit/miss, latence p95 <1 ms en local, fragmentation mémoire.
4) Cache HTTP: Nginx microcaching ou Varnish
- Nginx: microcaching 60–120 s pour public non connecté; bypass via cookies (logged_in, preview, panier).
- Varnish: VCL pour gérer ESI/cookies; TTL courts + stale-while-revalidate pour limiter les « cache stampedes ».
- Invalidation: webhooks/ban sur publication, purge sélective par URL, tag ou clé.
- CDN: activer HTTP/3, « cache everything » là où c’est compatible, « origin shield » et règles d’expiration par type. Utiliser stale-if-error pour résilience.
- Navigateur: Cache-Control max-age=31536000, immutable sur assets versionnés; ETag/Last-Modified sur HTML.
6) Mesurer, tester, itérer
- Avant/après: WebPageTest, Lighthouse, GTmetrix. Suivre TTFB, LCP, CLS et la courbe CPU/mémoire.
- Charge: k6, JMeter ou wrk pour tester hits/miss et stabilité sous pics.
- Observabilité: exporter métriques OPcache (taux de remplissage, restarts), Redis (hits/misses, evictions), reverse proxy (hit ratio, 5xx).
Paramètres recommandés OPcache 2026
- opcache.memory_consumption = 192M (petit/moyen site) à 256–384M (gros monolithes PHP)
- opcache.interned_strings_buffer = 16–32
- opcache.max_accelerated_files = 20000–40000
- opcache.validate_timestamps = 0 (prod); opcache.revalidate_freq = 0
FAQ express
- Faut-il encore utiliser XCache ? Non. Il n’est plus maintenu. OPcache, intégré à PHP 7/8, est la voie fiable et sécurisée.
- Redis ou Memcached ? Redis offre plus de fonctionnalités (persistance optionnelle, structures), Memcached est minimaliste. Pour WordPress, Redis est souvent préféré.
- Le cache casse mon site connecté. Que faire ? Bypassez le cache HTTP pour utilisateurs connectés et pages panier/compte; réduisez la durée (TTL) et implémentez une purge sélective.
- Mon hébergement gère-t-il cela facilement ? Des solutions managées simplifient l’activation des couches de cache. Voir aussi: VPS cPanel LWS: performant et facile à gérer.
Remerciements historiques: cet article modernise une contribution ancienne d’un client (entre-copines.be) qui partageait alors l’installation d’XCache. Le paysage a évolué: OPcache, Redis, Varnish et les CDN constituent désormais la base saine pour des sites rapides et stables.
En résumé, attaquez d’abord OPcache (coût faible, gains élevés), ajoutez Redis pour stabiliser la base de données, puis un cache HTTP et un CDN pour réduire la latence mondiale. Mesurez, ajustez les TTL et surveillez vos taux de hit: c’est la meilleure assurance performance en 2026.
