# wp_cache_get_multiple : grouper ses lectures plutôt que les multiplier une à une

> Vingt appels wp_cache_get successifs ou un seul wp_cache_get_multiple : pour un développeur soucieux de performance, la différence se mesure en allers-retours réseau évités.

- Auteur : Clément Hadrot
- Publié le : 2025-08-17
- Mis à jour le : 2025-08-17
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/wp-cache-get-multiple-grouper-lectures-cache/

## L’essentiel

- Chaque appel wp_cache_get isolé peut coûter un aller-retour réseau distinct
- wp_cache_get_multiple regroupe la lecture en une seule opération
- Le gain dépend du backend de cache utilisé, pas seulement du code

Vingt clés à lire, vingt appels à `wp_cache_get()` dans une boucle `foreach` : c'est le schéma le plus répandu pour récupérer un ensemble de valeurs mises en cache, et c'est aussi celui qui gaspille le plus de temps quand le backend de cache utilisé n'est pas la mémoire du processus PHP lui-même, mais un serveur distant comme Redis ou Memcached.

Ce billet ne traite pas les transients, qui reposent sur un mécanisme différent avec expiration intégrée en base de données en l'absence d'object cache persistant. Il porte sur l'API de cache d'objets bas niveau, et sur le moment où grouper ses lectures change réellement la donne pour la performance d'une extension.

## Ce que fait wp_cache_get_multiple

Disponible depuis WordPress 5.5, `wp_cache_get_multiple( array $keys, string $group = '' )` accepte un tableau de clés et renvoie un tableau associatif de résultats, chaque clé absente du cache étant associée à la valeur `false`. Avec un backend persistant qui communique par le réseau, cet appel unique traduit en une seule opération ce qui aurait autrement demandé une requête par clé.

```
$identifiants = [ 'produit_12', 'produit_45', 'produit_78' ];
$resultats = wp_cache_get_multiple( $identifiants, 'mon_extension' );

foreach ( $resultats as $cle => $valeur ) {
    if ( false === $valeur ) {
        // Absent du cache : à recalculer et à réinjecter individuellement
        continue;
    }
    // Utiliser $valeur normalement
}
```

## Pourquoi le gain dépend entièrement du backend en place

> L'essentiel à retenir : Chaque appel wp_cache_get isolé peut coûter un aller-retour réseau distinct ; wp_cache_get_multiple regroupe la lecture en une seule opération ; Le gain dépend du backend de cache utilisé, pas seulement du code

Sur une installation qui n'utilise aucun plugin d'object cache persistant, WordPress retombe sur un cache purement en mémoire du processus PHP courant : dans ce cas, `wp_cache_get()` et `wp_cache_get_multiple()` n'impliquent aucun aller-retour réseau, et le gain de regroupement reste marginal, limité à quelques appels de fonction PHP évités. La situation change radicalement avec un backend comme Redis : chaque appel `wp_cache_get()` isolé se traduit alors par une commande réseau distincte vers le serveur de cache, avec sa latence propre, même minime individuellement.

Sur vingt clés lues une à une, cette latence s'additionne vingt fois. Un appel groupé à `wp_cache_get_multiple()` se traduit, selon l'implémentation du backend, par une seule commande groupée — l'équivalent d'un `MGET` côté Redis — ce qui ramène ces vingt allers-retours à un seul.

## Quand grouper ses lectures fait une vraie différence

- Une boucle qui affiche une liste d'éléments dont chacun nécessite une lecture de cache individuelle : regrouper les identifiants avant la boucle d'affichage, puis parcourir le résultat déjà récupéré.
- Un rendu de widget qui interroge plusieurs compteurs indépendants (nombre de vues, nombre de favoris, note moyenne) pour un même élément : ces clés peuvent être lues en un seul appel groupé plutôt que trois appels séparés.
- Une tâche de synchronisation qui vérifie l'état en cache de plusieurs centaines d'éléments avant de décider lesquels retraiter.

## Un exemple concret : afficher une liste sans multiplier les lectures

```
function afficher_compteurs_produits( array $produit_ids ) {
    $cles = array_map( fn( $id ) => "compteur_vues_{$id}", $produit_ids );
    $compteurs = wp_cache_get_multiple( $cles, 'produits' );

    foreach ( $produit_ids as $id ) {
        $cle = "compteur_vues_{$id}";
        $valeur = $compteurs[ $cle ] ?? false;

        if ( false === $valeur ) {
            $valeur = recalculer_compteur( $id );
            wp_cache_set( $cle, $valeur, 'produits' );
        }
        echo esc_html( "Produit {$id} : {$valeur} vues" );
    }
}
```

La lecture groupée initiale ne remplace pas la nécessité de recalculer et de réinjecter les clés absentes individuellement : elle évite seulement de multiplier les lectures pour les clés déjà présentes, ce qui reste le cas le plus fréquent en régime de croisière.

## Ne pas grouper à outrance non plus

Grouper deux mille clés en un seul appel n'est pas forcément préférable à un découpage en lots de quelques centaines : un appel unique trop volumineux peut, selon la configuration du backend, se heurter à des limites de taille de commande ou de temps de réponse. La bonne pratique consiste à grouper par lot de taille raisonnable, adaptée au volume habituel d'une même page ou d'une même tâche, plutôt que de chercher à tout regrouper en un seul appel géant.

## Notion à retenir

Grouper ses lectures d'object cache n'apporte un bénéfice mesurable qu'en présence d'un backend persistant qui communique par le réseau. Sur un cache purement en mémoire de requête, l'optimisation reste anecdotique. Le bon réflexe consiste donc à identifier d'abord le backend réellement utilisé sur l'environnement cible, puis à regrouper les lectures dès qu'une boucle appelle `wp_cache_get()` plus de quelques fois de suite pour des clés connues à l'avance.