Un WordPress qui traîne malgré un cache de page actif souffre presque toujours du même mal : trop d'allers-retours vers la base de données. Deux caches se confondent régulièrement dans ce diagnostic. Le cache de page — LSCache sous LiteSpeed — enregistre le HTML final d'une page publique et le ressert sans redémarrer WordPress ni PHP. L'object cache — Redis, sujet de ce tutoriel — garde en mémoire les résultats de requêtes SQL et les options WordPress ; il agit après que PHP a démarré, sur les pages que LSCache ne peut pas mettre en cache : back-office, panier, compte client. Ce guide installe Redis pour WordPress sous LiteSpeed, du contrôle de disponibilité côté serveur jusqu'à la mesure du gain sur le TTFB et le nombre de requêtes base de données. Prérequis : Redis actif côté hébergeur, accès à un plugin d'administration et au fichier wp-config.php.
L'essentiel en un coup d'œil
| Question | Réponse courte |
|---|---|
| Cache de page ou cache objet ? | LSCache sert le HTML ; Redis décharge les requêtes SQL et wp_options |
| Quand Redis apporte un gain ? | Sites dynamiques, WooCommerce, visiteurs connectés, wp_options volumineux |
| Quand Redis est inutile ? | Petit site vitrine déjà bien servi par LSCache, trafic quasi entièrement anonyme |
| Où l'activer chez Tomco ? | Enhance Panel → site → Redis, sans installation serveur côté client |
| Constantes à ajouter | WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_DATABASE, WP_CACHE dans wp-config.php |
Redis change la donne sur les sites dynamiques : WooCommerce (sessions, transients de stock), espaces membres, intranets, ou tout WordPress dont la table wp_options dépasse plusieurs mégaoctets à cause de plugins mal rangés. Sur un site vitrine statique de quelques pages, déjà servi à l'essentiel depuis LSCache, l'installation ajoute une couche opérationnelle pour un gain qui ne se mesure pas : le cache de page couvre déjà le trafic anonyme, largement majoritaire sur ce profil de site.
Vérifier que Redis est disponible pour WordPress
Redis doit tourner côté serveur avant toute installation de plugin ; ce tutoriel ne couvre pas la compilation ou l'installation du service lui-même. Sur les offres Tomco, Redis est disponible nativement sur chaque offre mutualisée et VPS : le service tourne déjà sur le serveur, prêt à être activé pour un site précis, sans compilation ni serveur tiers à maintenir côté client.
Activation côté Tomco. Depuis Enhance Panel : Hébergement → site concerné → onglet Redis → Activer. Le panneau attribue automatiquement un index de base dédié et affiche l'hôte et le port à reporter dans wp-config.php à l'étape suivante.
Vérifier l'extension PHP. Le pont entre WordPress et Redis passe par l'extension PECL redis, pas par un simple appel réseau :
php -m | grep -i redis
# redisAbsence de résultat = l'extension n'est pas chargée pour la version PHP active du site. Chez Tomco, elle est maintenue à jour à chaque montée de version PHP, y compris sur PHP 8.5.
Tester la connexion au service. Avec un accès SSH :
redis-cli -h 127.0.0.1 -p 6379 ping
# PONGPONG confirme que le service répond. Sans accès SSH, le statut du plugin (étape « Activer et vérifier ») sert de vérification équivalente.
Installer le plugin object cache
Deux voies mènent au même résultat, avec un arbitrage simple.
| Option | Quand la choisir |
|---|---|
| Redis Object Cache (plugin dédié) | Hébergement sans LiteSpeed Cache installé, ou réglages Redis avancés (clustering, réplication) |
| LiteSpeed Cache — onglet Object Cache | LSCache déjà installé pour le cache de page : un seul plugin gère les deux caches |
Sur une infrastructure LiteSpeed où LSCache gère déjà le cache de page, activer son onglet Cache → Object évite d'installer un second plugin et centralise les réglages. Le plugin autonome Redis Object Cache reste pertinent en dehors de LiteSpeed, ou pour des réglages Redis fins non exposés par LSCache.
Installation du plugin dédié via WP-CLI, si retenu :
wp plugin install redis-cache --activateLe plugin s'appuie sur l'API objet cache native de WordPress (WP_Object_Cache), documentée par developer.wordpress.org : chaque fonction wp_cache_get() / wp_cache_set() du cœur et des plugins passe par ce point d'entrée, que le backend soit Redis, Memcached, ou la mémoire de la requête en cours sans persistance.
Configurer wp-config.php
Le plugin installé, la connexion à Redis se déclare par constantes dans wp-config.php, au-dessus de la ligne /* That's all, stop editing! */ :
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 3);
define('WP_REDIS_TIMEOUT', 1);
define('WP_CACHE', true);WP_REDIS_DATABASE isole les clés d'un site sur une base Redis dédiée (index numérique, 0 à 15 par défaut) : indispensable dès qu'un serveur mutualisé héberge plusieurs installations WordPress sur la même instance Redis, pour éviter qu'une purge sur un site n'efface le cache d'un autre. Sur Enhance Panel, cet index est attribué automatiquement à l'activation et déjà reporté dans les réglages affichés.
WP_CACHE à true est requis pour que WordPress charge le drop-in object-cache.php — sans cette ligne, le plugin reste installé mais inactif.
Activer et vérifier
Le drop-in se copie dans wp-content/ en une commande WP-CLI :
wp redis enable
# Object cache enabled.Cette commande place object-cache.php à la racine de wp-content/, le fichier que WordPress charge avant tout plugin pour router les appels wp_cache_*() vers Redis. Vérification du statut :
wp redis status
# Status: Connected
# Client: PhpRedis
# Drop-in: ValidDrop-in: Valid confirme que le fichier object-cache.php présent correspond à la version du plugin actif — un Drop-in: Invalid après une mise à jour de plugin se corrige en relançant wp redis enable. Sans WP-CLI, la page de réglages du plugin (Redis Object Cache, ou onglet LiteSpeed Cache → Object) affiche le même statut de connexion.
Observer le trafic réel entre WordPress et Redis, requête par requête :
redis-cli monitorChaque rafraîchissement d'une page WordPress fait apparaître des commandes GET et SET dans le flux — signe que le cache objet est effectivement sollicité, pas seulement déclaré actif.
Régler et sécuriser
Trois réglages évitent les mauvaises surprises en production.
Base dédiée par site. Sur un serveur mutualisé, ne jamais partager l'index WP_REDIS_DATABASE entre plusieurs installations WordPress : une purge (wp cache flush) sur un site viderait le cache de tous les autres sites partageant le même index. Chez Tomco, un index dédié est attribué par site dès l'activation dans Enhance Panel.
Politique d'éviction. Redis doit pouvoir libérer de la mémoire sous pression sans faire planter WordPress. La politique allkeys-lru (Least Recently Used) évince les clés les moins récemment utilisées en premier, adaptée à un usage cache pur :
maxmemory-policy allkeys-lruRéglage géré côté serveur sur l'infrastructure Tomco, sans intervention côté client.
Mot de passe. Si le service Redis est exposé au-delà de localhost — un VPS avec Redis distant, par exemple — un mot de passe s'ajoute côté serveur (requirepass) et côté WordPress via une constante supplémentaire :
define('WP_REDIS_PASSWORD', 'valeur-generee-par-l-hebergeur');Sur un Redis lié à 127.0.0.1 uniquement, comme c'est le cas par défaut chez Tomco, le port n'est jamais exposé à l'extérieur du serveur : le mot de passe devient une défense en profondeur plutôt qu'une nécessité stricte.
Exclusions. Les groupes de cache volatils du cœur WordPress restent non persistants par défaut (recalculés à chaque requête plutôt que stockés dans Redis) : aucune exclusion manuelle n'est nécessaire dans une installation standard.
Mesurer le gain
La preuve se lit à deux endroits : le temps de réponse serveur et le nombre de requêtes base de données par page.
TTFB avant/après, sur une page non cachable par LSCache (tableau de bord wp-admin, compte client, panier) :
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://exemple.fr/wp-admin/Sur un WordPress à base de données chargée — dizaines de milliers de lignes wp_options et wp_postmeta, plusieurs dizaines de plugins actifs — l'infrastructure Tomco mesure un TTFB de l'ordre de 500-600 ms sur ces pages sans cache objet, contre 100-150 ms une fois Redis activé, un ordre de grandeur cohérent avec la réduction de plus de 70 % des requêtes base observée sur les pages connectées WooCommerce.
Requêtes base de données par page, avec le plugin Query Monitor : l'onglet Database affiche le nombre total de requêtes SQL et leur temps cumulé. Sur le même profil de site, ce compteur passe d'une centaine de requêtes à moins de trente une fois le cache objet actif — les lectures répétées de wp_options, taxonomies et métadonnées de menu ne retournent plus à la base.
Effet cumulé avec LSCache. Les deux caches ne se recouvrent pas : LSCache sert le HTML complet en 20-50 ms pour un visiteur anonyme sur une page déjà en cache, sans jamais démarrer PHP. Redis prend le relais exactement là où LSCache ne peut rien — pages connectées, panier, back-office — en déchargeant la base plutôt que le rendu HTML.
Sur l'infrastructure Tomco, les deux couches se cumulent sans configuration croisée : un hébergement WooCommerce combine par exemple l'ESI LiteSpeed pour les fiches produit publiques et Redis pour les sessions et paniers, chacun gagnant sur son propre segment de trafic. Le réglage détaillé du cache de page reste couvert par le guide configurer LiteSpeed Cache pour WordPress, préalable recommandé avant Redis — la configuration côté serveur, elle, est déjà en place sur tout hébergement web Tomco.
