function get_widget_data( $ids ) { foreach ( $ids as $id ) { wp_cache_get( $id, 'widgets' ); } } : ce code, trouvé dans un endpoint personnalisé qui alimentait un front headless, faisait exactement ce qu’on lui demandait, mais de la pire façon possible. Pour construire la réponse d’un bloc de contenus recommandés, l’endpoint interrogeait l’objet cache un identifiant à la fois, jusqu’à trente appels distincts pour une seule requête HTTP entrante.
La fonction wp_cache_get_multiple(), disponible dans le cœur de WordPress, existe précisément pour ce cas : elle regroupe plusieurs lectures de l’objet cache en un seul appel, ce qui réduit le nombre d’allers-retours vers le backend de cache (souvent Redis ou Memcached en production) derrière un site à fort trafic.
Le problème : une boucle de lectures individuelles
Voici la version initiale de l’endpoint, qui reconstruisait la liste des contenus recommandés en interrogeant l’objet cache un par un dans une boucle :
function recuperer_contenus_recommandes( $ids ) {
$resultats = array();
foreach ( $ids as $id ) {
$valeur = wp_cache_get( $id, 'contenus_recommandes' );
if ( false !== $valeur ) {
$resultats[ $id ] = $valeur;
}
}
return $resultats;
}Avec un objet cache persistant comme Redis, chaque appel wp_cache_get() génère un aller-retour réseau. Trente identifiants signifient trente allers-retours, exécutés séquentiellement, avant même de commencer à construire la réponse JSON de l’endpoint.
Le correctif : regrouper les lectures
wp_cache_get_multiple() accepte un tableau de clés et retourne un tableau associatif de résultats en un seul appel :
function recuperer_contenus_recommandes( $ids ) {
$bruts = wp_cache_get_multiple( $ids, 'contenus_recommandes' );
return array_filter( $bruts, function ( $valeur ) {
return false !== $valeur;
} );
}Sur l’endpoint testé, ce changement a fait passer trente appels réseau distincts vers le backend de cache à un seul appel groupé, pour une réponse JSON strictement identique côté front.
Variantes selon le nombre de clés demandées
Le gain observé n’est pas linéaire dans tous les cas. Sur un serveur où l’objet cache persistant tourne en local, sur la même machine que PHP, la latence réseau entre les appels reste négligeable, et le gain de wp_cache_get_multiple() devient surtout perceptible à partir d’une dizaine de clés demandées simultanément. En dessous, la différence se mesure en fractions de milliseconde, difficilement visible sur un temps de réponse global d’un endpoint REST.
- Moins de 5 clés : gain marginal, la boucle initiale reste acceptable.
- Entre 10 et 50 clés : gain net et mesurable, la fonction groupée devient pertinente.
- Au-delà de 50 clés : penser à découper la demande en plusieurs lots, pour éviter une réponse du backend de cache trop volumineuse d’un coup.
Le cas où ce correctif ne sert à rien
Sans objet cache persistant configuré (c’est-à-dire avec le cache d’objet par défaut de WordPress, qui ne survit pas d’une requête HTTP à l’autre), wp_cache_get_multiple() n’apporte aucun bénéfice : chaque requête entrante repart de zéro, et la fonction groupée ne fait que regrouper des lectures qui, de toute façon, échoueraient systématiquement. Ce point mérite d’être vérifié avant d’attribuer un gain de performance à ce seul changement de code.
Optimiser un appel qui n’atteint jamais de cache persistant, c’est astiquer une pièce qui ne tourne pas : vérifiez d’abord la configuration avant de retoucher le code.
Vérifier la présence d’un objet cache persistant avant d’optimiser
Avant d’appliquer ce correctif, il vaut mieux confirmer que le site dispose bien d’un objet cache persistant actif. La fonction wp_using_ext_object_cache() retourne un booléen fiable pour ce diagnostic, directement exploitable dans un script de vérification ou même dans une simple requête WP-CLI :
wp eval 'var_dump( wp_using_ext_object_cache() );'Sur le projet concerné, cette vérification a confirmé la présence d’un objet cache Redis actif, ce qui a validé l’intérêt du passage à wp_cache_get_multiple() avant même de mesurer le gain final en conditions réelles.
En résumé
wp_cache_get_multiple() est un correctif simple et localisé, particulièrement pertinent dans un endpoint REST qui assemble une réponse à partir de plusieurs éléments indépendants. Son effet réel dépend du nombre de clés en jeu et de la présence d’un objet cache persistant correctement configuré en amont.
