# Les appels à get_option avant et après un cache objet persistant

> Mesurer précisément ce que change un cache objet persistant sur le volume d'appels à get_option, plutôt que de le supposer. Un protocole de mesure simple à reproduire.

- Auteur : Clément Hadrot
- Publié le : 2020-06-06
- Mis à jour le : 2020-06-06
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/get-option-avant-apres-cache-objet-persistant/

## L’essentiel

- get_option est appelée des dizaines de fois par chargement de page
- Sans cache persistant, chaque appel peut redevenir une requête SQL
- Le gain se mesure, il ne se suppose pas

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.

> L'essentiel à retenir : get_option est appelée des dizaines de fois par chargement de page ; Sans cache persistant, chaque appel peut redevenir une requête SQL ; Le gain se mesure, il ne se suppose pas

## 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

1. Installer Query Monitor et activer son panneau Cache d'objet.
2. Charger la page cible trois fois pour stabiliser le cache non persistant de la requête en cours.
3. Noter le nombre de requêtes SQL liées à `wp_options` dans le panneau Requêtes.
4. Désactiver puis réactiver le plugin de cache objet persistant, et répéter la mesure.
5. 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.