Nginx serveur cache pour WordPress

Par /

Prérequis : vous devez avoir à minima un VPS et la liberté d’installer ce que vous voulez (ce qui n’est pas le cas de O2switch). hostinger propose un VPS de ce calibre, DigitalOcean propose des instances à la demande.

Installer Nginx et PHP-FPM

# Mettre à jour le système
sudo apt update && sudo apt upgrade -y

# Installer Nginx
sudo apt install nginx -y

# Installer PHP-FPM et extensions nécessaires pour WordPress
sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl -y

Créer un dossier pour le cache Nginx

sudo mkdir -p /var/cache/nginx
sudo chown -R www-data:www-data /var/cache/nginx
sudo chmod -R 700 /var/cache/nginx

Configurer Nginx pour le cache

Éditer le fichier de site WordPress. Supposons que le site est dans /etc/nginx/sites-available/wordpress.conf.

server {
    listen 80;
    server_name ton-domaine.com www.ton-domaine.com;

    root /var/www/wordpress;
    index index.php index.html index.htm;

    # Cache configuration
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m use_temp_path=off;

    # Log files
    access_log /var/log/nginx/wordpress.access.log;
    error_log /var/log/nginx/wordpress.error.log;

    # Main location
    location / {
        try_files $uri $uri/ /index.php?$args;

        # Enable caching
        proxy_cache WORDPRESS;
        proxy_cache_valid 200 60m;  # Cache 200 responses 60 minutes
        proxy_cache_valid 301 302 10m;  # Cache redirects 10 minutes
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    }

    # PHP-FPM handling
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock; # Adapte selon ta version de PHP
    }

    # Disable caching for admin and login
    location ~* /(wp-admin|wp-login\.php) {
        proxy_cache off;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    # Static files caching
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|webp)$ {
        expires 30d;
        access_log off;
    }
}

Ici, proxy_cache_path définit le cache, sa taille (100m) et l’endroit où il est stocké. On active le cache pour les pages publiques, et on le désactive pour les pages d’administration ou login.

Tester la configuration Nginx

sudo nginx -t
sudo systemctl reload nginx

Activer le log de cache

tail -f /var/log/nginx/wordpress.access.log
  1. On devrait voir des en-têtes comme :
  • HIT → la page vient du cache.
  • MISS → la page vient du serveur PHP (premier chargement ou cache expiré).

Pour ajouter un en-tête qui montre si une page est en cache :

proxy_set_header X-Cache $upstream_cache_status;

Placez-le dans la section location /.

Conseils pour WordPress

  • Installe un plugin de cache léger (comme LiteSpeed Cache ou WP Super Cache) si tu veux contrôler le purging automatique, sinon Nginx ne sait pas quand le contenu change.
  • Les images et fichiers statiques (CSS/JS) peuvent être directement servis avec expires pour ne pas passer par PHP.
  • Configure un cron ou purge Nginx pour vider le cache si tu changes beaucoup de contenu.

Version sans plugin Cache côté WordPress

Il n’est pas obligé d’avoir un WP CACHE pour dire à Nginx quand c’est invalidé. La version sans WP CACHE est disponible sur cette page.

1. Nginx en mode cache simple (proxy_cache)

  • Nginx cache les réponses HTTP qu’il reçoit de ton backend (PHP-FPM pour WordPress).
  • Il ne connaît pas la logique métier de WordPress : il ne sait pas si un post a été édité, si un commentaire est ajouté, etc.
  • Donc, par défaut, Nginx utilise un TTL (proxy_cache_valid 200 60m) pour déterminer combien de temps garder la page.
  • Après expiration, il refait une requête à PHP-FPM.

💡 En résumé : Nginx “voit” seulement les codes HTTP et les headers, pas l’état de WordPress.

2. Comment invalider intelligemment le cache ?

Pour qu’un cache Nginx soit “intelligent” et se purge automatiquement quand WordPress change quelque chose :

  1. Plugins WordPress dédiés :
    • LiteSpeed Cache ou WP Rocket peuvent envoyer des commandes de purge au serveur Nginx via HTTP ou socket quand un post/page est mis à jour.
    • Le plugin sait quand une page devient “obsolète” et demande à Nginx de la supprimer du cache.
  2. Purge manuel via Nginx :
    • On peut créer une URL spéciale comme /purge/some-path que WordPress appelle via un hook save_post.
    • Cette URL est configurée pour supprimer les fichiers du cache correspondants.
  3. Cache-Control et ETag :
    • Si WordPress envoie les headers Cache-Control et ETag, Nginx peut les respecter pour savoir quand revalider une page.
    • Cela permet un cache plus dynamique sans toucher au filesystem.

En pratique : Nginx est très rapide pour servir le cache, mais il a besoin d’un signal externe pour savoir quand le contenu est obsolète. WordPress côté PHP ou un plugin fournit ce signal.

Retour en haut