« On a installé Redis, mais le site n’est pas plus rapide. » Cette remarque, reçue après le déploiement d’un object cache persistant sur un site associatif de mise en relation, a d’abord semblé indiquer une mauvaise configuration. La vérification a montré l’inverse : Redis fonctionnait parfaitement, chaque appel à wp_cache_get() et wp_cache_set() passait correctement par le backend persistant. Et pourtant, le temps de génération des pages n’avait pas bougé d’un millième de seconde.
Ce cas, loin d’être isolé, illustre une idée reçue tenace : un object cache persistant ne résout que les lenteurs qui passent réellement par les fonctions wp_cache_* de WordPress. Si le vrai goulet d’étranglement se situe ailleurs, son installation n’apporte strictement rien, aussi bien configurée soit-elle.
Premier cas : le goulet était un appel réseau externe
Sur le site associatif, le profilage a révélé que l’essentiel du temps de génération provenait d’un appel wp_remote_get() synchrone vers un service de vérification d’adresse postale, exécuté à chaque affichage du formulaire d’inscription. Cet appel réseau, totalement extérieur au périmètre de l’object cache (qui ne connaît que les données internes de WordPress via les fonctions wp_cache_*), continuait de s’exécuter intégralement à chaque requête, quelle que soit la qualité du cache d’objets installé en parallèle.
La solution, dans ce cas précis, ne passait pas par le cache d’objets mais par la mise en cache explicite du résultat de cet appel réseau spécifique, via un transient dédié à cette donnée, avec une durée de vie adaptée à la fréquence de changement réelle de l’information récupérée.
Deuxième cas : des requêtes SQL non couvertes par le cache
Sur un second site, une extension de recherche interne construisait ses requêtes directement via $wpdb->get_results() avec du SQL personnalisé, sans jamais passer par les fonctions de cache de WordPress. Ce type de requête directe reste totalement invisible pour l’object cache persistant : celui-ci ne met en cache que ce que le code applicatif lui demande explicitement de mettre en cache, il n’intercepte pas automatiquement toutes les requêtes SQL exécutées par WordPress ou ses extensions.
Troisième cas : un cache de page déjà suffisant
Sur un site éditorial majoritairement consulté par des visiteurs anonymes, le cache de page couvrait déjà la quasi-totalité du trafic réel. L’object cache persistant, ajouté ensuite dans l’espoir d’un gain supplémentaire, n’avait donc que très peu d’occasions de s’exercer : les pages qui auraient pu en bénéficier (contenu dynamique, visiteurs connectés) représentaient une part marginale du trafic total du site.
Un object cache ne remplace jamais un diagnostic préalable. Il accélère ce qui transite déjà par les bonnes fonctions, rien de plus, rien de moins.
Comment vérifier avant d’installer un object cache
- Profiler le temps de génération d’une page représentative avec un outil comme Query Monitor, en identifiant la répartition entre requêtes SQL, appels externes, et calculs PHP purs.
- Vérifier quelle proportion des requêtes SQL identifiées transite déjà par des fonctions
wp_cache_*ou par l’API Transients, seules bénéficiaires directes d’un object cache persistant. - Comparer la part de trafic anonyme, déjà couverte par un éventuel cache de page, à la part de trafic dynamique qui pourrait réellement profiter d’un cache d’objets.
- Mesurer à nouveau après installation, sur les mêmes pages, dans les mêmes conditions, pour objectiver le gain réel plutôt que de se fier à une impression.
Ce que cela signifie pour un budget d’optimisation
- Un object cache persistant n’est pas une dépense à engager par défaut, mais une réponse à un diagnostic précis qui l’a identifié comme pertinent.
- Le temps investi dans son installation et sa maintenance mérite d’être comparé à une correction ciblée du code réellement responsable de la lenteur observée.
- Un site déjà bien couvert par un cache de page peut légitimement se passer d’un object cache persistant, sans que cela ne relève d’une négligence technique.
En résumé
Un object cache persistant n’est pas une solution universelle : il n’accélère que ce qui passe par son périmètre d’action précis. Avant de l’installer en réponse automatique à une plainte de lenteur, un profilage ciblé permet de vérifier qu’il répond bien au vrai goulet d’étranglement du site concerné, plutôt que d’ajouter une couche technique sans effet mesurable.
