The WordPress REST API powers headless frontends, mobile apps, and third-party integrations. As API usage grows, response times can degrade without proper caching. Unlike page caching which caches HTML output, API caching must handle JSON responses, authentication states, and varying query parameters. Implementing API caching reduces server load and improves response times for API consumers.
This guide covers how to implement caching for the WordPress REST API.
Cache Headers
The simplest form of API caching is proper HTTP cache headers. Set Cache-Control headers on your REST API responses to allow CDNs and browsers to cache them. Use the rest_post_dispatch filter to add cache headers to responses. Set public cache for public data and private cache for authenticated responses. Include max-age to control cache duration.
Use ETags and Last-Modified headers for conditional requests. The WordPress REST API generates ETags automatically from response content. Clients can send If-None-Match headers to check if content has changed without downloading the full response.
Server-Side Caching
Cache REST API responses on the server side using the WordPress Transients API or object cache. Wrap expensive API calls in a transient check — return cached data if available, generate fresh data if not. Set cache duration based on how frequently the underlying data changes. For collection endpoints, cache for shorter periods. For single resource endpoints, use longer cache durations.
Invalidate cached API responses when the underlying data changes. Hook into post save, delete, and update actions to clear relevant cache entries.
CDN Caching
Serve REST API responses through a CDN for global performance. Configure your CDN to cache API responses based on the URL and query parameters. Use cache keys that vary by authentication state — unauthenticated users get cached public responses while authenticated users bypass the cache. Cloudflare, BunnyCDN, and KeyCDN all support API response caching.
Set appropriate cache purge rules. When content changes, purge only the affected API endpoints rather than the entire cache.
GraphQL Caching
If you use WPGraphQL instead of the REST API, caching works differently. GraphQL queries are POST requests that can’t be cached as easily as REST GET requests. Use persisted queries — storing query definitions on the server and sending only the query ID — to enable CDN caching. Implement dataloader caching to batch and cache database queries within a single GraphQL request.
For client-side caching, use Apollo Client or URQL with normalized cache that stores entities by ID and type.
Cache Invalidation
Cache invalidation is the hardest part of API caching. When content changes, all cached responses that include that content must be invalidated. Implement a cache tagging system — assign tags to cached responses based on the resources they include. When a resource changes, purge all cached responses with its tag. WordPress hooks like save_post, delete_post, and updated_post_meta trigger invalidation.
The Bottom Line
REST API caching is essential for headless WordPress and API-heavy applications. Use HTTP cache headers for browser and CDN caching, server-side caching with transients for database query results, CDN caching for global performance, and cache tags for targeted invalidation. Proper API caching reduces response times from hundreds of milliseconds to single digits.
