Cache de site web & cache côté serveur : comment fonctionne le cache WordPress
En examinant le cache de site web et le cache côté serveur sur le serveur qui héberge ce site, j'ai constaté que les requêtes de pages WordPress descendent dans l'ordre navigateur, CDN, cache de page, OPcache et Redis, et s'arrêtent à la première couche qui possède une copie. Les requêtes de pages arrivées directement sur le serveur d'origine ont reçu de nginx le fichier HTML créé par WP Rocket, sans jamais descendre jusqu'à PHP ni à la base de données.
Ⅰ. Structure du cache WordPress
En informatique, le cache est une technique qui stocke temporairement des données pour y accéder rapidement ; sur le web, il fonctionne selon le même principe et contribue largement aux performances.
En stockant des données, la mise en cache évite de tout redemander au serveur à chaque visite : les données stockées se chargent vite et le temps de chargement des pages diminue. Cela réduit la charge du serveur et améliore l'expérience utilisateur.
Les caches utilisés par les requêtes WordPress se divisent en deux branches : le cache de site web et le cache côté serveur. La norme de cache HTTP, telle que la décrit MDN, distingue le cache stocké dans le seul navigateur d'un visiteur (private cache) des caches CDN et proxy partagés par de nombreux visiteurs (shared cache) ; cet article regroupe les deux sous le nom de cache de site web.
Le cache de page, OPcache et le cache d'objets s'insèrent dans le processus d'exécution de WordPress sur le serveur. La norme HTTP ne leur donne pas de catégorie propre ; la classification vient de la documentation officielle de WordPress: extensions de cache (cache de page), cache d'objets et cache serveur (caches d'opcode comme OPcache).
Pour l'ensemble des domaines où le cache est utilisé, voir l'article Cache : définition et tous les domaines où la mise en cache est utilisée ; pour les quatre branches de l'optimisation des performances, cache compris, voir l'article Optimisation des performances web : structure et définition qui y est consacré.
Dans le simulateur ci-dessous, choisissez un cache dans l'arborescence de gauche et appuyez sur un bouton : vous verrez à quelle couche la requête s'arrête. La première couche qu'un administrateur WordPress active avec une extension de cache est le cache de page.
| Couche | Emplacement | Ce qui est stocké | Exemple Nginx + Apache |
|---|---|---|---|
| Cache du navigateur | Appareil du visiteur | HTML · CSS · JS · images · polices | CSS · images 7 jours |
| CDN · cache proxy | Devant le serveur (edge · proxy inverse) | Copies des pages · fichiers statiques | Bunny CDN |
| Cache de page | Disque · mémoire du serveur | HTML produit par PHP | WP Rocket + nginx |
| OPcache | Mémoire du serveur | Bytecode PHP | PHP 8.3, JIT désactivé |
| Cache d'objets | Mémoire du serveur | Résultats de requêtes · objets | Redis |
Ⅱ. Cache de site web
Le cache de site web, c'est le navigateur du visiteur et le CDN ou le proxy qui enregistrent une copie selon les consignes de stockage que le serveur indique dans ses en-têtes de réponse. Les en-têtes typiques sont [Cache-Control], [ETag] et [Expires] ; une fois la durée de conservation écoulée, une requête conditionnelle ([304 Not Modified]) vérifie si le contenu a changé.
1️⃣ Cache du navigateur
Le cache du navigateur est le cache HTTP stocké dans le navigateur web du visiteur : il conserve HTML, CSS, JavaScript, images et polices et, lorsqu'une même ressource est demandée à nouveau, soit il ne va pas jusqu'au serveur, soit il vérifie seulement si elle a changé.
La durée de conservation est fixée par le serveur, pas par le visiteur. Le serveur Nginx + Apache ci-dessous attribue 7 jours aux CSS et aux images, et sert les pages HTML sans durée, pour qu'elles soient vérifiées à chaque nouvelle visite.
If-None-Match: "6ab12775-2ee8"cache-control: max-age=604800 expires: Sat, 17 Oct 2026 03:21:00 GMT etag: "6ab12775-2ee8"
etag: "6ac9298c-95575" last-modified: Fri, 09 Oct 2026 17:51:08 GMT
2️⃣ CDN · cache proxy
Le cache CDN ou proxy est un cache partagé par de nombreux visiteurs, placé entre eux et le serveur d'origine. Un proxy direct se trouve du côté des visiteurs, comme dans un réseau d'entreprise, tandis que les proxys inverses et les CDN se placent devant le serveur et répondent avec une copie stockée à la place du serveur d'origine.
Un proxy inverse typique est Varnish Cache, et les CDN comme Bunny CDN ou Akamai suivent la même structure. Avec un DNS géographique, les visiteurs de la région du serveur d'origine peuvent être reliés directement à ce serveur, tandis que les visiteurs d'autres régions reçoivent la réponse d'un edge CDN proche (par exemple Bunny CDN), qui stocke même le HTML.
Pour la structure et les avantages d'un CDN, voir l'article Qu'est-ce qu'un CDN ? Pourquoi l'utiliser et ses 5 avantages qui y est consacré.
Ⅲ. Cache côté serveur
Le cache côté serveur intervient une fois la requête arrivée sur le serveur d'origine, pendant que WordPress génère la page. Un serveur configuré avec Nginx + Apache traite les requêtes dans l'ordre ci-dessous ; si une étape trouve une copie, les suivantes sont sautées.
Une configuration Nginx + Apache peut être choisie en option chez Cloudways et ScalaHosting. Chez Cloudways, vous choisissez pour chaque application soit la pile hybride (Nginx + Apache), soit la pile Lightning (Nginx seul) ; chez ScalaHosting, vous pouvez activer dans SPanel un réglage qui place Nginx devant Apache.
| Cache | Ce qui est stocké | Quand c'est stocké |
|---|---|---|
| 1️⃣ Cache de page | Page HTML terminée | 🅑 ⑤ À la réponse, WP Rocket l'enregistre dans un fichier |
| 2️⃣ OPcache | Code PHP compilé (bytecode) | 🅑 ② À la première exécution d'un fichier PHP |
| 3️⃣ Cache d'objets | Fragments de données comme les résultats de requêtes et les options | 🅑 ③ La première fois que WordPress récupère les données |
1️⃣ Cache de page
Le cache de page est aussi appelé cache de page complète (full-page cache) et, comme il stocke du HTML, parfois cache HTML. Il enregistre toute la page web produite par PHP sous forme de fichier HTML statique et, pour la même requête de page, envoie ce fichier sans exécuter PHP. C'est le cas 🅐 dans l'ordre de traitement ci-dessus.
Il est stocké dans la mémoire (RAM) ou sur le disque (HDD/SSD) du serveur : la mémoire est rapide mais coûteuse et limitée, le disque offre beaucoup d'espace mais reste comparativement lent.
| Type | Exemple | Stockage et réponse |
|---|---|---|
| Extension de cache | WP Rocket · WP Super Cache · W3 Total Cache · Cache Enabler | WordPress enregistre la page dans un fichier HTML, que le serveur web envoie. |
| Cache du serveur web | Cache FastCGI de Nginx · LiteSpeed Cache | Le serveur web stocke lui-même la réponse PHP et l'envoie à la requête suivante. |
| Cache de proxy inverse | Varnish | Un serveur de cache placé devant le serveur web stocke la page et répond. |
Avec Nginx + Apache, nginx lit et envoie directement le fichier HTML créé par WP Rocket, et l'en-tête de réponse porte [x-rocket-nginx-serving-file: HIT]. Pour activer et configurer le cache de page avec WP Rocket, voir l'article Guide de configuration WP Rocket qui y est consacré.
2️⃣ OPcache
OPcache stocke en mémoire le code PHP précompilé en bytecode, si bien que le parseur PHP n'intervient plus lorsque le même fichier est réexécuté. Il est intégré par défaut depuis PHP 5.5 ; APC et XCache, utilisés autrefois, ne prennent pas en charge PHP 7 et ne servent plus aujourd'hui. Cela correspond à l'étape ② de 🅑 dans l'ordre de traitement ci-dessus.
| Type | Statut | Description |
|---|---|---|
| Zend OPcache | Intégré depuis PHP 5.5 | Le cache d'opcode standard actuel, activé avec [opcache.enable=1]. |
| OPcache JIT | Inclus dans OPcache depuis PHP 8 | Convertit encore une fois le bytecode en code machine avant de l'exécuter ; activé ou désactivé avec [opcache.jit]. |
| APC | Abandonné | Le cache d'opcode utilisé avant OPcache ; sa fonction de cache de données se poursuit dans APCu. |
| XCache | Abandonné | Ne prend pas en charge PHP 7. |
| WinCache | Pour serveurs Windows (IIS) | Un cache d'opcode que la documentation officielle de WordPress cite à côté d'OPcache. |
OPcache s'active avec le réglage PHP [opcache.enable=1], et le JIT, arrivé avec PHP 8, peut être désactivé à part avec [opcache.jit=disable]. Pour l'installation et la configuration, voir l'article Zend OPcache : concept, installation et configuration qui y est consacré.
3️⃣ Cache d'objets
Le cache d'objets stocke les résultats des requêtes à la base de données ou les objets calculés dans un stockage en mémoire comme Redis ou Memcached. Par défaut, WordPress ne garde les objets en mémoire que le temps d'une requête ; il faut lui adjoindre un stockage comme Redis pour que les résultats subsistent après la requête. Cela correspond à l'étape ③ de 🅑 dans l'ordre de traitement ci-dessus.
| Type | Type | Conservé après la requête ? | Description |
|---|---|---|---|
| WP_Object_Cache | Par défaut dans WordPress | Non | Un cache intégré qui ne mémorise que le temps d'une requête. |
| Redis | Cache d'objets | Oui | Un stockage en mémoire distinct, relié via le drop-in de l'extension Redis Object Cache. |
| Memcached | Cache d'objets | Oui | Un stockage en mémoire distinct. |
| APCu | Cache d'objets | Oui (sur le même serveur) | Stocke dans la mémoire partagée utilisée par PHP. |
| Fichier | Cache d'objets | Oui | Stocke sous forme de fichiers sur le disque. |
| Pool de mémoire tampon InnoDB | Cache propre à la base de données · pas un cache d'objets | Oui | MySQL et MariaDB gardent en mémoire les données des tables et les index. |
| Cache de requêtes | Cache propre à la base de données · pas un cache d'objets | — | Supprimé dans MySQL 8.0 ; toujours présent dans MariaDB, mais désactivé par défaut. |
WordPress se connecte à Redis par le fichier drop-in ([object-cache.php]) qu'ajoute l'extension Redis Object Cache. Pour la procédure d'installation, voir l'article Installer et configurer Redis Cache sur WordPress qui y est consacré.
🔢 FAQ & contenus recommandés
ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur(il baisse lors des promotions ↓), lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.