Tutoriel pour mettre en place un cache WordPress haute performance sur un VPS avec OPcache et WP Super Cache

Le site SysKB, spécialisé dans les sujets Tech, Informatique et Business, est hébergé sur un VPS IONOS pour garantir performance et souplesse. Récemment, une augmentation notable du trafic a mis en lumière un ralentissement côté serveur, avec un temps de réponse dépassant régulièrement les 600 millisecondes, malgré l’utilisation d’un plugin de cache WordPress.

Ce tutoriel présente l’intégralité du processus d’optimisation mis en place pour corriger cette situation, jusqu’à atteindre un temps de réponse inférieur à 25 ms sur la page d’accueil.
Vous découvrirez pas à pas :

  • l’installation et la configuration de WP Super Cache en ligne de commande via WP-CLI,
  • la mise à jour des droits de fichiers pour assurer la bonne écriture du cache,
  • la correction manuelle du .htaccess pour garantir que les pages en cache soient bien servies par Apache,
  • et enfin, la mise en place d’un cron quotidien pour vider et recharger automatiquement le cache.

Chaque étape est documentée avec les commandes exactes, les pièges à éviter, et les tests de validation réalisés sur le site SysKB pour obtenir un résultat fiable et reproductible.

⚙️ Pré-requis

  • Un VPS Debian 11 (Bullseye) chez IONOS, accès root
  • Apache 2.4, PHP 8.2 avec OPcache actif
  • Un WordPress fonctionnel (dossier /var/www/html)
  • Connaissance basique de la ligne de commande SSH

🛠️ Étapes détaillées

1. Installer WP-CLI 🖥️

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp
wp --info        # Vérification

2. Installer & activer WP Super Cache ⚡

cd /var/www/html
wp plugin install wp-super-cache --activate --allow-root
wp option update wp_super_cache_status 1 --allow-root
wp option update wp_cache_mod_rewrite 1 --allow-root

3. Corriger les permissions 📂

chown -R www-data:www-data wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

4. Vérifier la génération de cache 🔍

curl -I https://syskb.com            # 1ᵉʳ test : devrait afficher 200 OK
ls -lah wp-content/cache/supercache/syskb.com/   # présence de index-https.html

5. Ajouter le bloc .htaccess adapté HTTPS ✍️

Placerez après # END WordPress :

# BEGIN WPSuperCache (HTTPS)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ [NC]

# GZIP
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html.gz [L]

# HTML
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html [L]
</IfModule>
# END WPSuperCache

🔄 Redémarrez Apache : systemctl restart apache2

6. Tester le temps de réponse 🚀

curl -o /dev/null -s -w "%{time_total}\n" https://syskb.com
# Attendu : < 0.05 (chez SysKB : 0.022 s)

7. Créer le script de rafraîchissement quotidien 🗓️

cat <<'EOF' >/usr/local/bin/wp-cache-refresh.sh
#!/bin/bash
SITE_PATH="/var/www/html"
DOMAIN="https://syskb.com"

rm -rf "$SITE_PATH/wp-content/cache/supercache"/*
curl -s "$DOMAIN" > /dev/null
# Ajoutez d’autres URLs si besoin
echo "[\$(date)] Cache vidé & préchargé." >> /var/log/wp-cache-refresh.log
EOF
chmod +x /usr/local/bin/wp-cache-refresh.sh

8. Planifier le cron à 3 h du matin ⏰

crontab -e
# Ajoutez :
0 3 * * * /usr/local/bin/wp-cache-refresh.sh

9. Vérifier le log 📝

tail /var/log/wp-cache-refresh.log

⚠️ Conseils & erreurs à éviter

  • Ne pas exécuter WP-CLI en root sans --allow-root si vous êtes pressé ; idéalement utilisez l’utilisateur www-data.
  • Vérifiez que mod_rewrite est activé : a2enmod rewrite && systemctl restart apache2.
  • Si votre site est en HTTPS, adaptez bien le nom du fichier cache (index-https.html).
  • Pensez à OPcache : sans lui, vos gains seront moindres.
  • Surveillez les logs : /var/log/apache2/error.log et /var/log/wp-cache-refresh.log.

🎯 Résultat attendu

  • Temps de réponse serveur < 50 ms pour les visiteurs anonymes
  • Charge CPU réduite (Apache sert des fichiers statiques)
  • Cache vidé et préchargé automatiquement chaque nuit

❓ FAQ

WP Super Cache fonctionne-t-il avec HTTPS ?

Oui. Toutefois, il faut adapter le fichier .htaccess pour qu’il redirige vers index-https.html, généré par WP Super Cache pour les pages servies via HTTPS.

Pourquoi je ne vois pas l’en-tête X-WP-Super-Cache ?

Cet en-tête est uniquement injecté lorsque WordPress sert la page via PHP. Si Apache sert directement le fichier HTML (ce qui est optimal), aucun en-tête PHP n’est ajouté. C’est un bon signe.

Comment savoir si le cache fonctionne ?

Utilisez la commande suivante en SSH :

curl -I https://votresite.com

Si vous voyez Last-Modified et Content-Length, mais aucun en-tête PHP, le cache statique est bien en place.

Dois-je vider le cache manuellement après chaque mise à jour ?

Oui, si vous ne configurez pas un système de nettoyage automatique. C’est pour cela qu’un cron quotidien est recommandé pour purger et précharger le cache sans intervention manuelle.

Que faire si le cache ne se génère pas ?

Vérifiez les points suivants :

  • Le plugin est activé
  • Les permissions sur wp-content permettent l’écriture
  • Le fichier .htaccess contient les bonnes règles de réécriture
  • Un visiteur (ou curl) a bien déclenché la génération du cache

Laisser un commentaire