Developing for the WordPress REST API opens up tons of possibilities for how we communicate with the database from the front-end of websites and apps. Whether you are using a custom endpoint created by
register_rest_route, or just adding custom data to the output of an existing endpoint through
register_rest_field, it often makes sense to cache some of this data.
Here are a few approaches I’ve taken on production sites that have helped speed up response times for me.
Use the Transient API, Carefully
WordPress transients can be used to store basically anything. Since they’re stored in the
wp_options table however, this approach should be used sparingly, and usually with data that is somewhat global in nature. To illustrate — if you had 10,000 entries of a post type and used a transient to store data for each entry, that would lead to the options table becoming 10,000 rows longer (not good). We’ll handle this particular use-case later in this post by using the post meta API.
For now, let’s set a transient that contains a 3rd party API response, and then add it to our own custom endpoint response.
Now instead of calling the 3rd party API directly in your endpoint, just call the
yournamespace_rest_transient_example function to check for the cached response first. If the transient doesn’t exist, it will call the API and store the response.
You can test the actual performance boost this gives you by A/B testing the response time of your endpoint in Postman with the first
get_transient() call commented out. Your mileage may vary depending on your server configuration and how expensive the queries you are making are.
Clearing the transient
It often makes sense to delete your custom post meta data whenever a post is saved, although you could choose to just wait until it expires.
Use Post Meta for Expensive Queries
For data that is expensive to generate and is related to a post, it can make sense to store the data in the post’s meta for a defined period of time. We’re essentially recreating the idea of transients but storing them in the
wp_postmeta table. First we generate some data and save it to the post’s meta along with an expiration date. Then, in future calls to the endpoint we’ll check if this stored data exists, and return the stored version instead of generating it again from scratch.
This only makes sense if generating the new data takes longer than looking it up from the database. So if your endpoint is handling some complex queries, or using a 3rd party API, this can make a noticeable difference. Here’s how to set things up.
Register your endpoint or custom field and callback function
Generate the data and save in post meta with an expiration key
This is where the magic happens. In our helper function called
yournamespace_get_post_transient(), we are first checking to see if the data exists in the post meta. If it does and it’s not expired, we can just return it directly. If not, then we generate the data from scratch but store it an array along with an expiration time. Again, this probably only makes sense if the data we are generating is complex.
In your app, whenever you call your endpoint you can now expect to see a cached version of the response output you defined in the
Deleting the post meta value
Notice the final function
yournamespace_delete_meta_transient which is hooked to
save_post. This will ‘bust the cache’ by deleting the custom meta value and then regenerating it when a posted is updated.
Make sure to test
The bottom line is that if the process of looking up the transient or post meta data that you have saved and returning it from the database costs more than it does to just generate the data on the fly – just generate the data on the fly. There is no way around this other than to test your endpoints with various caching methods turned on an off and compare results.