Un front Gatsby appelait WPGraphQL en POST à chaque build, ce qui fonctionnait très bien tant que le site restait statique. Le jour où le client a voulu un rendu à la demande côté serveur, ce même schéma d’appel est devenu un problème : impossible de mettre du cache HTTP standard sur une requête POST, et donc impossible de laisser un CDN absorber la charge.
L’extension WPGraphQL Smart Cache règle ce problème en deux temps : elle transforme les requêtes en appels GET cachables, puis elle se charge d’invalider ce cache au bon moment, sans intervention manuelle.
Des requêtes persistées pour sortir du POST
Le principe des requêtes persistées consiste à enregistrer côté serveur le texte complet d’une requête GraphQL, associé à un identifiant court. Le front n’envoie plus jamais la requête entière : il envoie son identifiant dans l’URL, en GET, ce qui la rend indiscernable d’une ressource HTTP classique aux yeux d’un cache ou d’un CDN.
GET /index.php?graphql_query_id=frontpage-hero&variables;={"slug":"accueil"}
Deux bénéfices concrets : la charge utile transmise sur le réseau diminue puisqu’on ne réenvoie plus le texte de la requête à chaque appel, et surtout, la porte s’ouvre pour un cache HTTP standard basé sur les en-têtes Cache-Control.
Le cache réseau proprement dit
Une fois les requêtes en GET, Smart Cache ajoute les en-têtes de cache adaptés aux réponses GraphQL et peut être combiné à n’importe quel CDN qui respecte ces en-têtes, qu’il s’agisse d’un proxy Varnish maison ou d’un service comme Cloudflare. C’est à ce moment que le passage à un rendu à la demande cesse de faire peur : chaque requête identique, pour un même visiteur ou pour mille visiteurs différents, ne touche le serveur WordPress qu’une seule fois par durée de cache.
L’invalidation, le vrai problème résolu
Un cache qu’on ne sait pas purger correctement finit toujours par servir du contenu périmé. Smart Cache s’accroche aux événements natifs de WordPress (publication, mise à jour, suppression d’un contenu, changement de menu, etc.) pour déterminer précisément quelles requêtes en cache dépendent de ce contenu, et déclenche leur purge automatiquement, sans configuration manuelle par type de contenu.
Ce que ça change concrètement
- Plus besoin d’un webhook de rebuild déclenché à l’aveugle sur chaque publication.
- Le cache peut être conservé longtemps, puisqu’il est invalidé au bon moment plutôt que sur une durée arbitraire courte.
- La purge peut se propager jusqu’au CDN si celui-ci expose une API de purge compatible.
Intégration avec un CDN externe
Pour qu’une purge WordPress se répercute jusqu’à un CDN, Smart Cache doit pouvoir déclencher un appel de purge vers ce CDN au moment de l’invalidation. Cette liaison se configure généralement via des identifiants d’API propres au service choisi, renseignés dans les réglages de l’extension. Sans cette liaison, l’invalidation reste locale au cache applicatif WordPress et le CDN continue de servir l’ancienne version jusqu’à expiration de son propre délai.
Sur un projet où le CDN n’était pas encore relié, on a gardé une durée de cache courte le temps de finaliser l’intégration : mieux vaut un cache un peu moins efficace qu’un contenu obsolète visible plusieurs heures.
Une différence à garder en tête
Ce mécanisme cache les réponses GraphQL elles-mêmes, en amont du serveur d’application. Il ne remplace pas un cache d’objets PHP ou un cache de page classique côté REST : il s’agit d’une couche spécifique à la couche réseau des requêtes GraphQL, avec sa propre logique d’invalidation liée au graphe de contenu plutôt qu’à des règles de durée génériques.
Notre verdict
Pour tout projet qui interroge WPGraphQL à la demande plutôt qu’au build, Smart Cache change la donne : le serveur WordPress cesse d’être sollicité à chaque visite et le contenu reste frais sans webhook artisanal à maintenir. Le seul vrai travail restant consiste à bien identifier, pour chaque requête, ce dont dépend sa fraîcheur — ce que l’extension fait déjà très correctement par défaut.
