500 visites en une heure sur un article dont la description générée par un modèle de langage n’a pas changé depuis sa publication : combien de ces 500 visites déclenchent, sans cache, un nouvel appel identique à l’API du modèle ? Sur un code non protégé, la réponse est simple : autant que de visites, ce qui revient à payer plusieurs centaines de fois le même résultat.
Le cache d’objet persistant de WordPress, via les fonctions wp_cache_get et wp_cache_set, répond directement à ce problème, à condition de choisir correctement le groupe de cache et la durée de vie associée à la clé.
Pourquoi ne pas se contenter d’une transient
Les transients, via get_transient et set_transient, offrent une API similaire mais persistent en base de données par défaut, en l’absence d’objet cache externe. Sur un site à fort trafic, cette persistance en base ajoute une charge d’écriture évitable, alors que le cache d’objet, lorsqu’il est soutenu par une extension comme Redis ou Memcached, reste en mémoire et se prête mieux à des lectures très fréquentes.
function obtenir_resume_ia( int $post_id ): ?string {
$cle = 'resume_' . $post_id;
$groupe = 'mon_plugin_ia';
$resume = wp_cache_get( $cle, $groupe );
if ( false !== $resume ) {
return $resume;
}
$resume = appeler_api_resume( $post_id );
if ( null === $resume ) {
return null;
}
wp_cache_set( $cle, $resume, $groupe, HOUR_IN_SECONDS * 6 );
return $resume;
}
Choisir un groupe de cache dédié
Le troisième paramètre de wp_cache_set, le groupe, isole les clés du plugin de celles utilisées par le cœur ou par d’autres extensions. Sans groupe dédié, une clé nommée simplement resume_42 pourrait entrer en collision avec une clé posée ailleurs dans le code, avec des conséquences difficiles à diagnostiquer.
add_action( 'init', function () {
wp_cache_add_global_groups( array( 'mon_plugin_ia' ) );
} );
Déclarer le groupe comme global via wp_cache_add_global_groups a un sens particulier sur une installation multisite : le cache devient alors partagé entre les différents sites du réseau plutôt que dupliqué pour chacun, ce qui convient à un contenu qui ne dépend pas du site courant.
Déterminer la durée de vie adaptée
Le choix du TTL dépend directement de la fréquence à laquelle le contenu source est susceptible de changer. Un résumé généré à partir du contenu d’un article ne devrait rester en cache que tant que l’article n’est pas modifié :
- Invalider explicitement la clé lors de la mise à jour de l’article, via
save_post - Fixer malgré tout un TTL de secours, pour couvrir les mises à jour effectuées hors du cycle normal de publication
- Éviter un TTL trop court qui annulerait le bénéfice du cache sans réduire significativement le risque d’un contenu périmé
add_action( 'save_post', function ( int $post_id ) {
wp_cache_delete( 'resume_' . $post_id, 'mon_plugin_ia' );
} );
Le cas des réponses à faible probabilité de répétition
Toutes les réponses de modèle de langage ne bénéficient pas également du cache. Une réponse générée à partir d’une saisie libre d’un visiteur, différente à chaque fois, n’a que peu de chances d’être redemandée à l’identique : mettre en cache ce type de réponse consomme de la mémoire sans bénéfice réel. Le cache trouve sa pertinence sur les contenus dérivés d’une source stable : un article, une fiche produit, une page.
Un cache mal ciblé coûte de la mémoire sans réduire la dépense réelle : mieux vaut réserver le cache d’objet aux réponses dérivées d’un contenu qui change rarement.
Vérifier la présence d’un objet cache persistant
Sur un hébergement sans extension de cache d’objet externe, wp_cache_set reste fonctionnel mais ne persiste qu’en mémoire pour la durée de la requête en cours, ce qui annule l’intérêt recherché ici. La fonction wp_using_ext_object_cache() permet de vérifier la présence d’un objet cache persistant avant de compter sur ce mécanisme pour réduire réellement les appels à l’API.
En résumé
Le cache d’objet persistant réduit efficacement les appels redondants à une API de modèle de langage, à condition de choisir un groupe dédié, d’invalider explicitement la clé lors des mises à jour de contenu, et de réserver ce mécanisme aux réponses issues d’un contenu source suffisamment stable pour justifier la mise en cache.
