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.
