WooCommerce REST API caching shipped as an experimental feature in 10.5, and it is aimed squarely at headless stores and mobile apps. After a decade of chasing WooCommerce performance problems, the REST API is still the part I trust least under load, especially once a React storefront or a busy mobile client starts hammering it.
It is not the only speed change in this release. Variation pricing got its own fix, which I covered in WooCommerce variation price caching. The difference is scope. Object caching cuts down the database queries behind a request; this engine caches the finished response. Early testing put the latency drop at up to 70%.
Why WooCommerce needed built-in REST API caching
Page caching plugins such as WP Rocket or W3 Total Cache are built for HTML, so they either skip REST endpoints or handle JSON badly. Hit /products on a catalog of 20,000 items and you feel every bit of that overhead. WooCommerce’s own testing put a cache miss at 2.5 seconds and a cache hit at 0.6 seconds. For an app that refetches products on every screen, that gap decides whether the interface feels alive.
How to implement WooCommerce REST API caching
Everything runs through the RestApiCache trait. You opt in per controller by wrapping the callback, so nothing changes until you ask for it. If you already run WooCommerce product object caching on your custom integrations, this is the same idea one layer up the stack.
Refactoring a standard controller takes two changes: pull in the trait, then pass the callback through with_cache.
<?php
// bbioon_example_controller.php
class Bbioon_Custom_Controller {
use RestApiCache; // The new experimental trait
protected function get_default_response_entity_type(): ?string {
return 'custom_endpoint';
}
public function register_routes() {
register_rest_route(
'bbioon/v1',
'/data',
array(
'methods' => WP_REST_Server::READABLE,
// Wrapping the callback enables the caching engine
'callback' => $this->with_cache( array( $this, 'get_item' ) )
)
);
}
public function get_item( $request ) {
// Your logic here
return new WP_REST_Response( array( 'status' => 'success' ), 200 );
}
}Headers and revalidation
Storage is only half of it. The engine builds an ETag hash from the response data, so a client can send If-None-Match on the next request. When nothing has changed, WooCommerce answers with 304 Not Modified and the client skips the download and the parse. The full implementation is in the RestApiCache trait on GitHub.
Where it breaks: Nginx and cache invalidation
Plenty of experimental features have died on me in production for reasons that had nothing to do with the code, and server config is usually the reason. Nginx is the common culprit here: some setups strip the If-None-Match header outright, others rewrite the Date header. If your 304s never fire, send the value in a custom X-WC-If-None-Match header and put it back before dispatch:
<?php
add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
$custom_header = $request->get_header( 'X-WC-If-None-Match' );
if ( $custom_header ) {
$request->set_header( 'If-None-Match', $custom_header );
}
return $result;
}, 0, 3 );One more requirement. WooCommerce REST API caching needs a persistent object cache, Redis or Memcached, to hold the responses. Without one you still get the HTTP header behavior, but the server rebuilds every response from scratch.
If WooCommerce REST API caching is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days.
What ships in 10.5
The feature is experimental and off by default. Turn it on under WooCommerce → Settings → Advanced → Features. Coverage today is mostly the product endpoints on v2, v3 and v4, though the trait is generic enough that we can extend it to custom entities. The original call for testing sits on the WooCommerce Developer Blog, along with the GitHub discussion board where they are collecting results.
