A client came to me last month with a big store: thousands of SKUs, plus a high-frequency inventory sync running against their warehouse. Their complaint was that REST API response times kept swinging. The same GET call would come back in 200ms one minute and 400ms the next. That is the sort of thing you cannot un-notice once a client has pointed it out, and it bothered me as much as it bothered them.
I went to the MySQL slow query logs first, assuming an unindexed meta query or some plugin doing expensive work on every hit. An hour went into tuning buffers and checking object cache hit rates before I accepted that the queries were fast. The database was not the bottleneck. The cost sat in the boot time of the WooCommerce REST API performance stack itself, which is not a place you think to look unless you already suspect it.
The 100ms tax you did not know you were paying
Before WooCommerce 10.4, every REST API request, down to a tiny heartbeat check, had to register every controller namespace. That included the heavy wc-analytics namespace. In a standard environment, registering those analytics routes alone could take over 100ms of execution time. You paid for it on requests that never touched analytics at all.
As I read in the official developer advisory, WooCommerce has now dealt with this by lazy loading the analytics namespace. Instead of registering everything upfront, the system checks whether the current route actually needs the analytics controllers and skips them when it does not.
What lazy loading changes
Registration happens on demand through the rest_pre_dispatch hook. Hit a standard /orders or /products endpoint and the whole analytics engine never loads. That shows up directly in Time to First Byte (TTFB). On lean requests in my own testing it came out to nearly 100ms.
If you build extensions that hook into the analytics namespace, go and check them. The registration order has shifted, so anything that depends on a strict rest_api_init sequence can trip over it. That is rare, but it does happen. A filter will turn lazy loading back off if you genuinely need the old behavior, though I would treat that as a stopgap while you fix the dependency rather than something you leave in place.
/**
* Disable lazy loading for specific namespaces if things get messy.
*
* @param bool $should_lazy_load Whether to lazy load.
* @param string $namespace The REST namespace being checked.
* @return bool
*/
add_filter( 'woocommerce_rest_should_lazy_load_namespace', function( $should_lazy_load, $namespace ) {
// If you're seeing weird route registration order issues:
if ( 'wc-analytics' === $namespace ) {
return false;
}
return $should_lazy_load;
}, 10, 2 );Where this leaves you
A slow endpoint is not always a slow query. Sometimes it is the framework loading code the request will never call. WooCommerce is getting leaner, and keeping your integrations fast means tracking those shifts rather than assuming last year’s profile still holds. Headless setups and high-traffic stores that lean on the REST API get the most out of this one.
If you are tired of debugging an integration someone else built and you would rather the site just worked, drop my team a line. We have probably seen it before.
If you have not looked at your staging site since the update, it is worth auditing how your REST API controllers register.
