27 requêtes SQL en moins sur le seul chargement de la page d’accueil : c’est l’écart mesuré, sur un site de test, entre une installation WordPress sans cache d’objet persistant et la même installation avec Redis actif derrière wp_cache_get(). Le chiffre surprend souvent les développeurs qui pensaient que get_option() était une fonction bon marché par construction.
Elle l’est, en un sens : WordPress charge déjà en une seule requête, tôt dans le cycle de chargement, toutes les options marquées comme autoload, et les place dans un cache d’objet non persistant valable pour la durée de la requête HTTP en cours. Le problème apparaît pour les options qui ne sont pas autoloadées, ou quand ce cache non persistant doit être reconstitué à chaque nouvelle requête, faute de persistance entre les visiteurs.
Le protocole de mesure utilisé
Pour isoler l’effet réel du cache objet, la méthode la plus fiable consiste à activer Query Monitor, désactiver temporairement tout plugin de cache objet persistant, charger la page cible trois fois de suite pour stabiliser les mesures, puis noter le nombre de requêtes contenant wp_options dans le panneau des requêtes SQL. On répète ensuite l’opération avec un cache objet Redis actif, sans rien changer d’autre à la configuration.
Sur le site de test utilisé ici, thème par défaut avec une dizaine de plugins courants, le nombre de requêtes liées à wp_options hors autoload est passé de 31 sans cache persistant à 4 avec Redis actif, ces 4 requêtes correspondant à des lectures de valeurs volontairement exclues du cache par certains plugins pour garantir leur fraîcheur.
Pourquoi l’écart n’est pas de 100 %
Certaines options restent lues directement en base à chaque requête par construction, notamment quand un plugin appelle get_option() avec le paramètre de valeur par défaut désactivé volontairement pour forcer une relecture, ou quand une extension de sécurité vérifie explicitement une option sensible sans passer par le cache pour éviter tout risque de valeur périmée. Il ne faut donc jamais viser un écart de 100 % comme objectif : viser la disparition des lectures redondantes suffit.
Ce que révèle l’onglet Cache de Query Monitor
Query Monitor affiche, dans son panneau Cache d’objet, le nombre de lectures (hits) et d’échecs (misses) pour la durée de la requête HTTP courante. Sur la mesure faite ici, le taux de hit atteignait déjà 94 % avec Redis actif dès la première visite après un redémarrage du service, preuve que la plupart des options fréquemment lues restent stables entre deux chargements de page.
Un indicateur à surveiller dans la durée
Un taux de hit qui se dégrade progressivement sur plusieurs jours signale souvent un plugin qui invalide trop largement le cache, ou une limite de mémoire atteinte sur le service Redis qui force l’éviction anticipée de clés encore utiles. Ce dernier point mérite une vérification régulière de maxmemory et de la politique d’éviction configurée.
Comment reproduire cette mesure sur un site existant
- Installer Query Monitor et activer son panneau Cache d’objet.
- Charger la page cible trois fois pour stabiliser le cache non persistant de la requête en cours.
- Noter le nombre de requêtes SQL liées à
wp_optionsdans le panneau Requêtes. - Désactiver puis réactiver le plugin de cache objet persistant, et répéter la mesure.
- Comparer les deux relevés sur plusieurs pages types du site (accueil, article, page catégorie).
Mesurer avant d’agir évite le piège le plus fréquent en optimisation WordPress : croire qu’un cache résout un problème qu’il ne fait en réalité qu’atténuer partiellement.
En résumé
Le cache d’objet persistant ne rend pas get_option() gratuite, il évite simplement de repayer le coût d’une requête SQL à chaque nouvelle visite pour des valeurs qui changent rarement. La bonne pratique reste de mesurer ce gain sur son propre site, avec ses propres plugins, plutôt que de se fier à un chiffre générique trouvé ailleurs : la composition exacte des extensions actives fait varier le résultat du simple au triple.
