# Mettre en cache les réponses de l’API REST WordPress côté serveur

> Chaque requête REST relance des requêtes SQL. Sur un front à fort trafic, le cache côté serveur devient vite indispensable : voici comment le mettre en place.

- Auteur : Clément Hadrot
- Publié le : 2020-12-15
- Mis à jour le : 2020-12-15
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/cache-reponses-api-rest-wordpress-cote-serveur/

## L’essentiel

- Cache applicatif avec WP REST Cache pour les routes publiques
- En-têtes HTTP standards pour le cache CDN
- Invalidation ciblée à la publication ou modification

Un client dont le front Gatsby interrogeait l'API REST WordPress à chaque build a vu son temps de build passer de 40 secondes à plus de 3 minutes une fois son catalogue de contenus dépassé les 800 articles. La cause : chaque requête vers `/wp-json/wp/v2/posts` déclenchait une série de requêtes SQL non négligeable (articles, termes de taxonomie associés, méta-données), sans aucune mise en cache entre deux appels identiques. Ce problème touche aussi bien les builds statiques que les fronts avec rendu à la demande.

Trois niveaux de cache peuvent intervenir sur une route REST : le cache applicatif (au niveau de WordPress lui-même), les en-têtes HTTP de cache, et un cache CDN en amont du serveur. Cet article couvre les deux premiers en détail, le troisième de façon plus rapide car il dépend fortement de l'hébergeur.

## Cache applicatif avec WP REST Cache

L'extension WP REST Cache intercepte les réponses des routes REST publiques et les stocke dans le cache d'objets de WordPress (transients par défaut, ou Redis/Memcached si configuré). À la requête suivante identique, la réponse est servie depuis le cache sans recalcul.

> L'essentiel à retenir : Cache applicatif avec WP REST Cache pour les routes publiques ; En-têtes HTTP standards pour le cache CDN ; Invalidation ciblée à la publication ou modification