La documentation du standard HTTP décrit stale-while-revalidate comme une extension de Cache-Control qui permet à un cache de continuer à servir une réponse expirée pendant une fenêtre de temps définie, tout en déclenchant en parallèle une nouvelle requête vers le serveur d’origine pour rafraîchir cette réponse au bénéfice du visiteur suivant.
Sur un site WordPress à fort trafic, cette directive répond à un problème précis : l’expiration simultanée d’une entrée de cache très demandée provoque un pic de requêtes vers PHP au moment exact où le cache expire, plusieurs visiteurs arrivant dans cette fenêtre déclenchant chacun une régénération complète de la page. Avec stale-while-revalidate, un seul visiteur déclenche la revalidation en arrière-plan, tous les autres continuant de recevoir la version encore en cache sans attendre.
Syntaxe de la directive
Cache-Control: max-age=60, stale-while-revalidate=600
Cette configuration indique qu’une réponse reste fraîche pendant 60 secondes. Passé ce délai, et pendant les 600 secondes suivantes, un cache compatible peut encore servir cette réponse tout en la rafraîchissant en tâche de fond. Au-delà de ces 660 secondes cumulées, la réponse est considérée comme réellement périmée et doit être régénérée avant d’être servie à nouveau.
Ce que cela change concrètement pour le visiteur
Le visiteur qui arrive juste après l’expiration des 60 premières secondes reçoit la réponse en cache instantanément, sans percevoir aucun ralentissement, alors même qu’une nouvelle version se prépare en parallèle sur le serveur. Le visiteur suivant, quelques secondes plus tard, reçoit déjà la version fraîchement régénérée, sans jamais avoir eu à attendre le temps de génération complet.
Où cette directive s’applique-t-elle sur une pile WordPress ?
Le support de stale-while-revalidate dépend entièrement de la couche de cache HTTP placée devant WordPress : certains CDN et proxies de cache la respectent nativement, d’autres l’ignorent silencieusement en traitant la réponse comme simplement expirée. Avant de s’appuyer sur cette directive en production, il faut vérifier explicitement, dans la documentation du CDN utilisé, qu’elle est bien prise en charge, plutôt que de supposer un comportement universel.
Une limite à connaître
Cette directive ne remplace pas un cache de page WordPress classique côté serveur : elle s’applique au niveau du cache HTTP intermédiaire, entre le visiteur et le serveur d’origine. Sur un contenu qui change rarement (une page de conditions générales, une fiche produit stable), l’intérêt reste limité ; elle prend tout son sens sur un contenu à fort trafic et modérément dynamique, comme une page d’accueil éditoriale mise à jour plusieurs fois par jour.
Comparaison avec une expiration classique
| Situation | Cache-Control classique | Avec stale-while-revalidate |
|---|---|---|
| Juste après expiration | Requête bloquante vers l’origine | Réponse en cache immédiate |
| Pic de trafic à l’expiration | Risque de surcharge simultanée | Une seule revalidation déclenchée |
| Fraîcheur perçue | Stricte | Légèrement différée, contrôlée |
Combiner avec stale-if-error pour la résilience
Une directive voisine, stale-if-error, complète utilement ce dispositif : elle autorise un cache à continuer de servir une réponse périmée si le serveur d’origine renvoie une erreur lors de la tentative de revalidation, plutôt que de propager cette erreur au visiteur. Combinées, ces deux directives permettent à un site WordPress de continuer à répondre normalement, avec un contenu légèrement daté, même lors d’un incident temporaire côté serveur PHP ou base de données.
Cache-Control: max-age=60, stale-while-revalidate=600, stale-if-error=86400
Avec ce réglage, une panne de courte durée du serveur d’origine devient totalement invisible pour le visiteur, qui continue de recevoir une version fonctionnelle du site pendant que l’incident est traité en coulisse, un comportement particulièrement précieux lors d’une maintenance planifiée ou d’un pic de charge inattendu.
En résumé
stale-while-revalidate déplace le coût de la régénération d’une page en dehors du chemin critique perçu par le visiteur, au prix d’une fraîcheur légèrement moins stricte, acceptable sur la grande majorité des contenus éditoriaux. Sa mise en œuvre reste conditionnée au support effectif de la directive par la couche de cache HTTP réellement utilisée devant le site.
