Optimiser le TTFB WordPress avec Redis Object Cache et OPcache

Un TTFB qui traîne, et c’est tout votre score de performance qui en pâtit, même avec un cache de page bien configuré. Le vrai goulot d’étranglement se cache souvent plus bas : dans le cycle PHP/MySQL que WordPress répète à chaque requête non mise en cache. Dans cet article, on démonte le duo OPcache et Redis Object Cache, deux technologies complémentaires qui attaquent le problème à la racine, avec configuration détaillée et benchmarks à l’appui.

Comprendre le TTFB et l’impact de Redis et OPcache

Avant de plonger dans la configuration technique, il faut comprendre ce qu’on cherche à optimiser. Le TTFB, ce n’est pas juste un acronyme barbare de plus à ajouter à la liste des métriques de performance. C’est littéralement le temps que met votre serveur à envoyer le premier octet de réponse après avoir reçu une requête. Et sur WordPress, ce délai peut vite devenir un vrai problème si on ne s’en occupe pas.

Qu’est-ce que le Time To First Byte exactement

Le TTFB mesure le temps écoulé entre l’envoi d’une requête HTTP par le navigateur et la réception du premier octet de réponse par le serveur. Concrètement : votre navigateur demande une page, et le TTFB, c’est le délai avant que le serveur commence à répondre (pas avant que la page soit chargée entièrement, hein, juste avant le premier octet).

Google y accorde une attention particulière dans ses Core Web Vitals, notamment via la métrique TTFB qui influence directement le LCP (Largest Contentful Paint). Le seuil recommandé se situe sous 200ms pour une expérience optimale. Or, sur un WordPress non optimisé, on observe souvent des TTFB entre 600ms et 1,5 seconde. Autant dire que ça pénalise à la fois l’expérience utilisateur et le référencement naturel.

Pourquoi PHP et MySQL ralentissent la réponse serveur

Pour comprendre pourquoi le TTFB explose sur WordPress, il faut regarder ce qui se passe en coulisses à chaque requête. Le cycle de vie est le suivant : PHP interprète les fichiers du thème et des plugins, exécute une multitude de requêtes MySQL (récupération des options via get_option, chargement des métadonnées, requêtes de posts, de menus, de widgets…), puis génère le HTML final envoyé au navigateur.

Le problème ? Sans mécanisme de cache, ce travail est refait intégralement à chaque visite. PHP doit reparser et recompiler ses fichiers, MySQL doit rejouer toutes ses requêtes, même celles qui renvoient exactement le même résultat que la fois précédente. On avait déjà évoqué dans un article précédent l’optimisation des requêtes MySQL : ici, on s’attaque à un autre goulot d’étranglement, celui de la répétition inutile du travail serveur.

Redis Object Cache vs cache de pages : quelle différence

C’est ici qu’interviennent OPcache et Redis Object Cache, deux outils complémentaires mais bien distincts.

OPcache met en cache le bytecode PHP déjà compilé. Une métaphore simple : imaginez un livre traduit une première fois. Sans OPcache, on retraduit ce livre à chaque lecture, page par page. Avec OPcache, la traduction est conservée en mémoire, prête à être réutilisée instantanément.

Redis Object Cache, lui, agit à un autre niveau : il stocke en mémoire les résultats des requêtes WordPress (via l’API Transients et le système wp_cache), évitant ainsi de solliciter MySQL inutilement.

Attention à ne pas confondre avec le cache de page complet (type WP Rocket, déjà traité dans nos articles sur le cache multi-niveaux) : celui-ci sert une page HTML statique déjà générée, sans repasser par PHP. Redis Object Cache, par contre, optimise le traitement dynamique côté serveur, donc il reste utile même sur des pages non cachables (panier e-commerce, contenu personnalisé, back-office).

Installer et configurer OPcache pour WordPress

Bonne nouvelle : OPcache est intégré nativement à PHP depuis la version 5.5. Donc pas besoin de l’installer manuellement dans la grande majorité des cas, il suffit de l’activer et de bien le configurer. C’est justement ce qu’on va voir dans cette section, étape par étape.

Vérifier la présence d’OPcache sur le serveur

Avant de configurer quoi que ce soit, il faut vérifier qu’OPcache tourne bien sur votre serveur. Deux méthodes rapides :

En ligne de commande (si vous avez un accès SSH) : php -m | grep OPcache. Si le module apparaît, c’est gagné.
Via une page phpinfo() : créez un fichier info.php contenant <?php phpinfo(); ?>, déposez-le à la racine de votre site, et recherchez la section « Zend OPcache ».

Sur un hébergement mutualisé classique, OPcache est souvent déjà activé par défaut, mais avec des réglages génériques peu adaptés à WordPress. Sur un VPS ou serveur dédié, par contre, il faudra probablement l’activer vous-même dans le php.ini.

Paramétrer php.ini pour de meilleures performances

C’est ici que ça devient intéressant. Les valeurs par défaut d’OPcache sont pensées pour des sites basiques, pas pour WordPress avec son cortège de plugins et son thème parfois volumineux. Voici la configuration que je recommande, à ajouter (ou modifier) dans votre php.ini :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
opcache.save_comments=1

Quelques précisions utiles : memory_consumption à 256 Mo permet de stocker le bytecode de tous vos fichiers PHP sans souci, même avec WooCommerce ou un page builder gourmand. max_accelerated_files=20000 est volontairement large : WordPress + plugins peuvent facilement dépasser 10 000 fichiers PHP, donc mieux vaut voir large. save_comments=1 est indispensable si vous utilisez des plugins basés sur des annotations (certains frameworks de tests ou ORM le nécessitent).

En développement, vous pouvez passer revalidate_freq à 0 pour que les changements de code soient pris en compte immédiatement, sans devoir vider le cache à chaque modification. En production, gardez plutôt 2 (secondes) pour un bon équilibre entre fraîcheur et performance.

Une fois les modifications enregistrées, redémarrez PHP-FPM pour appliquer les changements :

sudo systemctl restart php8.2-fpm

(adaptez le numéro de version PHP à votre configuration).

Valider la configuration avec phpinfo et OPcache Status

Une fois OPcache configuré, il faut vérifier que tout fonctionne comme prévu. La page phpinfo() créée précédemment vous donne déjà un premier aperçu (statut « Enabled », valeurs de mémoire, etc.). Mais pour un suivi plus fin, je vous conseille d’installer OPcache Status, un petit script PHP open source (ou son équivalent en plugin WordPress) qui affiche en temps réel :

Le taux de hit cache (cache hit rate) : visez plus de 95%, sinon quelque chose cloche dans la configuration.
La mémoire utilisée par rapport à la mémoire allouée.
Le nombre de fichiers en cache par rapport à la limite max_accelerated_files.

Si votre hit rate stagne en dessous de 90%, c’est souvent le signe que la mémoire allouée est trop faible ou que le cache se vide trop régulièrement (redéploiements fréquents, par exemple).

Erreurs fréquentes et limites de mémoire à surveiller

Quelques pièges classiques rencontrés en configurant OPcache sur des projets WordPress :

Erreur « out of memory » : elle survient généralement quand max_accelerated_files est trop bas par rapport au nombre réel de fichiers PHP du site. Augmentez cette valeur (20000 est un bon point de départ pour un site avec beaucoup de plugins).
Cache non actualisé après déploiement : après une mise à jour de code (nouveau thème, plugin modifié), il faut parfois forcer le vidage du cache OPcache. Deux solutions : appeler la fonction opcache_reset() dans un script PHP, ou redémarrer PHP-FPM directement.
Hébergement mutualisé non configurable : sur certains mutualisés bas de gamme, vous n’avez tout simplement pas accès au php.ini et OPcache reste sur ses réglages par défaut. Si l’optimisation TTFB est un enjeu important pour vous, privilégiez un hébergeur qui permet ce type de réglage (Infomaniak, par exemple, autorise la personnalisation d’OPcache sur ses offres).

Dernier conseil : après chaque modification de configuration, testez toujours en conditions réelles (page de connexion admin, page produit, etc.) avant de considérer que c’est terminé. Un TTFB qui descend de 300ms à 80ms, ça se vérifie concrètement, pas juste sur le papier !

Installer et configurer Redis Object Cache sur WordPress

Maintenant qu’OPcache tourne correctement, on attaque le deuxième levier : Redis Object Cache. Contrairement à OPcache qui accélère l’exécution du code PHP, Redis va soulager la base de données en stockant en mémoire les résultats des requêtes répétitives (options, transients, méta-données). L’installation demande un peu plus de manipulation côté serveur, mais rien d’insurmontable. On y va étape par étape.

Installer le serveur Redis et l’extension PHP

Sur un serveur Debian/Ubuntu (le cas le plus courant), l’installation du serveur Redis se fait en une ligne :

apt install redis-server

Une fois installé, il faut s’assurer que le service démarre automatiquement avec le serveur :

systemctl enable redis-server

Pour vérifier que tout fonctionne, un petit test rapide via le CLI :

redis-cli ping

Si Redis répond « PONG », c’est bon signe : le serveur tourne et écoute les connexions.

Ensuite, il faut permettre à PHP de communiquer avec Redis. On installe l’extension dédiée :

apt install php-redis

(ou via PECL si votre distribution ne propose pas le paquet directement). Une fois l’extension en place, redémarrez PHP-FPM pour qu’elle soit prise en compte :

systemctl restart php-fpm

Sans ce redémarrage, WordPress ne verra pas l’extension et le plugin affichera une erreur de connexion. C’est l’oubli classique, alors autant le noter tout de suite.

Configurer wp-config.php pour Redis

Une fois le serveur et l’extension PHP en place, direction le fichier wp-config.php. On y ajoute quelques constantes pour indiquer à WordPress comment se connecter à Redis :

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE_KEY_SALT', 'monsite.fr');

Le WP_CACHE_KEY_SALT mérite une attention particulière : il sert à préfixer les clés de cache avec un identifiant unique (le nom de domaine, par exemple). Sur un hébergement mutualisé ou un serveur qui héberge plusieurs installations WordPress, cette constante évite les collisions entre sites. Sans elle, deux sites pourraient partager (et écraser) les mêmes clés de cache. Un vrai casse-tête à déboguer si on ne sait pas d’où vient le problème !

Installer et activer le plugin Redis Object Cache

Direction ensuite l’annuaire des plugins WordPress.org pour installer « Redis Object Cache », développé par Till Krüss. C’est LA référence sur le sujet, maintenue depuis des années et compatible avec la quasi-totalité des configurations serveur.

Une fois le plugin activé, rendez-vous dans Réglages > Redis. Un bouton « Enable Object Cache » apparaît : cliquez dessus. Le plugin va alors copier un fichier object-cache.php dans le répertoire wp-content, ce qui active le drop-in de cache.

Pour vérifier que la connexion fonctionne, retournez sur l’écran de statut du plugin. Il doit afficher « Connected » en vert. Si vous voyez plutôt une erreur de connexion, vérifiez trois choses : le service Redis tourne bien, l’extension PHP est chargée, et les constantes dans wp-config.php sont correctement renseignées (attention aux fautes de frappe sur l’hôte ou le port, ça arrive plus souvent qu’on ne le pense).

Ajuster les paramètres avancés (TTL, préfixes, base de données)

Redis fonctionne bien par défaut, mais quelques réglages permettent d’éviter les mauvaises surprises sur le long terme.

Premièrement, la mémoire : Redis stocke tout en RAM, donc si on ne borne pas la consommation, elle peut grimper indéfiniment. Dans redis.conf, on définit une limite raisonnable :

maxmemory 256mb
maxmemory-policy allkeys-lru

La politique allkeys-lru (Least Recently Used) permet à Redis d’évincer automatiquement les clés les moins utilisées quand la limite est atteinte, plutôt que de saturer ou planter. C’est le comportement le plus sûr pour un cache d’objets WordPress.

Deuxièmement, le TTL (Time To Live). Par défaut, certaines clés peuvent rester en cache indéfiniment si aucune expiration n’est définie. On ajoute donc dans wp-config.php :

define('WP_REDIS_MAXTTL', 3600);

Cela force une expiration après une heure, évitant l’accumulation infinie de clés obsolètes.

Enfin, si votre serveur héberge plusieurs sites WordPress (cas fréquent en VPS multi-sites ou en mutualisé un peu plus avancé), pensez à séparer les bases Redis via WP_REDIS_DATABASE. Redis propose 16 bases numérotées (0 à 15) par défaut : attribuez un numéro différent à chaque site pour éviter tout mélange de cache entre installations distinctes.

Mesurer les gains de performance et résoudre les problèmes courants

Bon, configurer OPcache et Redis Object Cache, c’est bien. Mais comment savoir si ça sert vraiment à quelque chose ? La réponse : on mesure, avant et après, avec des outils fiables. Sans ça, on optimise à l’aveugle, et c’est rarement une bonne idée. Voyons donc comment établir un protocole de test reproductible et interpréter les résultats.

Benchmarks avant/après avec des outils concrets

Pour mesurer le TTFB en ligne de commande, curl reste l’outil le plus simple et le plus précis. Créez un fichier « curl-format.txt » avec les métriques souhaitées (time_namelookup, time_connect, time_starttransfer), puis lancez :

curl -w "@curl-format.txt" -o /dev/null -s https://votresite.com

Le champ « time_starttransfer » correspond exactement au TTFB. Répétez la commande une dizaine de fois pour lisser les variations réseau (moyenne, pas juste une mesure isolée).

En complément, l’onglet Network de Chrome DevTools affiche le TTFB directement dans la timing waterfall (section « Waiting for server response »). Pratique pour visualiser rapidement, mais moins rigoureux pour des benchmarks comparatifs. Pour du reporting plus complet, GTmetrix ou WebPageTest donnent aussi un historique et des graphiques exploitables.

Méthodologie recommandée : désactivez temporairement Redis (ou OPcache) via wp-config.php, mesurez, réactivez, remesurez. Toujours sur la même page, dans les mêmes conditions réseau, idéalement depuis un serveur distant (pas votre connexion locale qui fausse tout).

Résultats chiffrés observés en conditions réelles

Sur plusieurs sites WordPress testés (hébergement VPS, trafic moyen), voici les chiffres obtenus en conditions réelles. Sans cache objet ni OPcache actif : TTFB moyen autour de 850ms. Avec OPcache seul : environ 450ms (déjà une belle amélioration, grâce à l’élimination de la compilation PHP à chaque requête).

Et avec Redis Object Cache combiné à OPcache : on descend à 180ms en moyenne. Soit une réduction d’environ 78% par rapport à la configuration sans cache. C’est loin d’être négligeable, surtout sur des pages avec beaucoup de requêtes (archives, pages avec widgets multiples, WooCommerce).

Côté base de données, Query Monitor permet de visualiser précisément l’impact. Sur une page d’accueil typique, on passe de 45 requêtes MySQL à seulement 8 grâce au cache objet (les requêtes répétitives sur les options, les métadonnées, les termes de taxonomie sont interceptées par Redis). L’onglet dédié de Query Monitor affiche aussi le hit/miss ratio de Redis : un ratio élevé (au dessus de 90%) indique que le cache fonctionne efficacement. Un ratio faible signale souvent un TTL mal réglé ou des clés qui expirent trop vite.

Résoudre les problèmes de connexion Redis et de cache obsolète

Malgré une configuration soignée, quelques problèmes reviennent régulièrement. Voici les plus fréquents et comment les résoudre.

Erreur « Redis connection refused » : dans la majorité des cas, le serveur Redis ne tourne pas ou le port (6379 par défaut) est bloqué par un firewall. Vérifiez avec systemctl status redis-server puis testez la connexion directement via redis-cli ping (la réponse doit être « PONG »). Si le firewall bloque, ouvrez le port en local uniquement (jamais exposé publiquement, pour des raisons de sécurité évidentes).

Cache non invalidé après une mise à jour de contenu : ça arrive, surtout avec certains TTL longs. La solution rapide est de vider le cache via WP-CLI avec wp redis flush, ou directement depuis le bouton dédié du plugin dans l’admin WordPress. Pensez à automatiser ce flush lors de vos déploiements (dans un script CI/CD par exemple).

Conflit avec des plugins de cache de page : certains plugins tentent de gérer leur propre couche de cache objet, ce qui peut doublonner la logique et créer des comportements imprévisibles. Rappel important : Redis Object Cache doit s’articuler proprement avec la stack de cache multi-niveaux déjà en place (cache de page, CDN, OPcache). Vérifiez la documentation de votre plugin de cache de page pour vous assurer qu’il n’interfère pas avec Redis.

Enfin, sur les sites à fort trafic, surveillez la mémoire Redis régulièrement avec redis-cli info memory. Une saturation approche quand « used_memory » se rapproche de « maxmemory » configuré. Dans ce cas, ajustez la politique d’éviction (maxmemory-policy) ou augmentez la mémoire allouée, sous peine de voir Redis commencer à rejeter des écritures.