Sur un site WordPress sous forte charge, la première optimisation qui change vraiment la donne n’est ni un plugin ni un réglage PHP : c’est le cache de page au niveau du serveur web. Quand nginx peut répondre directement depuis un fichier mis en cache, sans jamais réveiller PHP-FPM ni interroger MySQL, le temps de réponse est divisé par quatre ou cinq dans la plupart des cas que nous rencontrons.
Le module fastcgi_cache de nginx fait exactement cela : il intercepte les réponses générées par PHP-FPM via FastCGI et les stocke sur disque pour les resservir telles quelles aux visiteurs suivants. C’est redoutablement efficace, mais aussi redoutablement dangereux si l’on oublie d’exclure les bonnes zones : personne ne veut qu’un visiteur voie le panier ou la session d’un autre utilisateur parce que la page a été mise en cache sans discernement.
Comprendre le fonctionnement de fastcgi_cache
Le principe est simple : nginx reçoit une requête, la transmet à PHP-FPM comme d’habitude, mais avant de renvoyer la réponse au navigateur, il en conserve une copie sur disque. À la requête suivante pour la même URL, si une copie valide existe, nginx la sert directement sans jamais toucher PHP-FPM. Cela signifie zéro exécution de code WordPress, zéro requête MySQL, pour toutes les visites qui tombent sur une page déjà en cache.
Contrairement à un plugin de cache comme WP Super Cache, qui génère des fichiers HTML statiques via PHP, fastcgi_cache travaille en amont de PHP : c’est nginx lui-même, écrit en C, qui décide de servir le cache. Le gain de performance est donc supérieur, au prix d’une configuration plus technique.
Configuration de base dans nginx
La configuration se fait en deux temps : une zone de cache déclarée dans le bloc http, puis son utilisation dans le bloc server ou location qui traite les fichiers PHP.
# Dans le bloc http, en dehors de tout server {}
fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header updating http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
La directive keys_zone=WORDPRESS:100m réserve 100 Mo de mémoire partagée pour les métadonnées du cache (environ 8 000 clés par Mo), et inactive=60m supprime automatiquement les entrées non consultées depuis une heure. fastcgi_cache_use_stale permet de resservir une version périmée si PHP-FPM tombe en erreur, ce qui évite une page blanche en cas de pépin côté PHP.
Exclure l’admin, le panier et les utilisateurs connectés
C’est l’étape la plus importante, et celle que l’on voit le plus souvent bâclée. Il faut définir des conditions qui empêchent la mise en cache pour tout ce qui est personnalisé par visiteur : back-office, pages de connexion, panier WooCommerce, commentaires postés récemment.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
set $skip_cache 1;
}
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
if ($http_cookie ~* "woocommerce_items_in_cart") {
set $skip_cache 1;
}
location ~ \.php$ {
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_valid 404 1m;
add_header X-FastCGI-Cache $upstream_cache_status;
include fastcgi_params;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
La variable $skip_cache pilote à la fois fastcgi_cache_bypass (ne pas servir depuis le cache) et fastcgi_no_cache (ne pas écrire dans le cache). Les deux doivent être positionnées ensemble : oublier l’une des deux crée des incohérences difficiles à déboguer.
Purger le cache proprement
Un cache qui ne se met jamais à jour est pire qu’une absence de cache : un article corrigé, un prix modifié sur une fiche produit, tout resterait figé jusqu’à expiration naturelle. Deux approches courantes :
- Compiler nginx avec le module tiers
ngx_cache_purge, qui ajoute la directivefastcgi_cache_purgeet permet de vider une clé de cache précise via une requête HTTP dédiée. - Utiliser une extension WordPress comme Nginx Helper, qui déclenche automatiquement une purge à chaque publication, modification ou commentaire, via les hooks
save_postetcomment_post.
Sans le module de purge sélective, la seule option reste de vider tout le répertoire de cache (rm -rf /var/cache/nginx/wordpress/*) ou d’attendre l’expiration fixée par fastcgi_cache_valid. C’est nettement moins élégant, mais parfaitement fonctionnel pour un site au contenu peu fréquemment modifié.
Vérifier que le cache fonctionne réellement
L’en-tête X-FastCGI-Cache ajouté dans la configuration ci-dessus renvoie l’une de ces valeurs, consultables avec curl -I :
MISS: la page n’était pas en cache, elle vient d’être générée par PHP-FPM ;HIT: la page a été servie directement depuis le cache ;BYPASS: la mise en cache a été volontairement contournée (session active, méthode POST, etc.) ;EXPIRED: l’entrée existait mais avait dépassé sa durée de validité.
Avant de mettre en production, testez systématiquement une session connectée en tant qu’administrateur puis en visiteur anonyme dans deux navigateurs différents. C’est le meilleur moyen de repérer une fuite de cache avant qu’un client ne le fasse à votre place.
En résumé
Le cache fastcgi_cache transforme un site WordPress lent en site capable d’encaisser un pic de trafic sans broncher, à condition de traiter la configuration avec la rigueur qu’elle mérite : zone de cache correctement dimensionnée, exclusions précises pour tout ce qui est personnalisé, et stratégie de purge alignée sur le rythme de publication du site. C’est un chantier technique, mais c’est aussi le gain de performance le plus radical qu’un développeur WordPress puisse offrir sans toucher une ligne de PHP.
