Why your WooCommerce REST API is slow

By Abdalla Kamesh · Published September 19, 2026 · 5 min read

Disclosure: this post links to Cloudways using affiliate links. If you start a plan through one, StoreToNative may earn a commission at no extra cost to you. The diagnosis below applies to any host; the Cloudways features named are cited from their own pages.

Here is a situation that confuses a lot of merchants: your store scores well on every speed tool, and your mobile app’s product screens still take a second and a half to fill.

Both observations are correct. They are measuring different things.

The measurement gap

Page-speed tools load an HTML page. On a WooCommerce store with page caching, that page is served from cache by Varnish or a plugin, without touching PHP or MySQL. Fast, and genuinely so — for that page.

Your app requests /wp-json/wc/v3/products and friends. Those responses are:

Not page-cached. They are API responses, often personalized, and page caches correctly exclude them.
Full-path. Every request runs PHP, hits MySQL, runs every plugin’s filters.
Numerous. An app opening makes several requests at once, not one.

So your API performance is your uncached performance, which is the number no speed tool shows you. That is the number your app’s perceived speed is made of. The background on which endpoints matter is in how a mobile app talks to WooCommerce.

Measure it first, in one command

Before changing anything, get a baseline from a machine that is not on your office wifi:

curl -o /dev/null -s -w "%{time_total}\n" \
  "https://yourstore.com/wp-json/wc/v3/products?per_page=20&consumer_key=…&consumer_secret=…"

Run it five times and take the median. Then interpret:

Under 300 ms — good. Your app will feel instant.
300–600 ms — acceptable. Worth improving.
600 ms–1.5 s — noticeable. This is where “the app feels slow” complaints start.
Over 1.5 s — fix this before doing anything else to the app.

Do the same for products?per_page=20&category=… with a filter applied, because filtered queries are the expensive ones.

The seven causes, in fix order

1. No persistent object cache

The biggest single win, almost every time. WordPress recomputes an enormous amount of option, meta and term data per request; without a persistent object cache it does that work again on every API call.

Turn on Redis. On Cloudways, Redis and Memcached are built in and Object Cache Pro is included on plans, which means the good implementation rather than a basic one. Enable it, then re-run your baseline. Halving the response time here is common.

Verify it is actually active, not merely installed — a Redis plugin that failed to connect looks identical to a working one from the admin screen.

2. Too few PHP workers

An app opening makes several simultaneous requests. If your host gives you two PHP workers, request three waits for one to finish. On shared hosting this is often the whole story, and it is not tunable — you buy your way out of it with dedicated resources.

Symptom: individual requests are fine, but the app is slow on launch, when several fire at once.

3. An old PHP version

PHP 8.x is materially faster than 7.4 running the same code. Cloudways lets you switch between 7.4, 8.0, 8.1, 8.3 and 8.4 per application, so this is a two-minute change with a rollback — test on staging first, because an old plugin is the only thing that makes it hard.

4. Plugins filtering every product

Every plugin hooking woocommerce_product_get_price or the product data filters runs once per product per response. Twenty products per page means twenty executions per request.

Diagnose by deactivating plugins on staging — never production — and re-running your baseline after each. Two or three plugins usually account for most of it.

5. Database work that needs RAM

Filtered catalog queries — two attributes plus a price range — are genuinely expensive. If your MySQL buffer pool is too small for your product tables, those queries hit disk.

Symptom: unfiltered product lists are fast, filtered ones are slow. Fix: more RAM, and make sure wp_postmeta is properly indexed (WooCommerce’s own tools and its lookup tables help here).

6. Oversized images in the response

This one is not the API’s latency, it is the app’s perceived latency. If the API hands back full-size image URLs, the app downloads 3 MB files to fill 400 px thumbnails. The response was fast; the screen still took two seconds to fill.

Fix: sensible source images, and confirm the app is requesting the generated intermediate sizes rather than the originals.

7. Geography

A US customer, a US app, and a server in another continent pays a round trip on every request. Nothing in software fixes that. Choose a server region near your customers — with Cloudways you pick the cloud provider and region at creation, which makes this a one-time decision rather than a migration.

What not to bother with

A CDN for the API. CDNs cache static assets; your API responses are dynamic and personalized. A CDN is worth having for images, not for wp-json.
More page-cache plugins. They do not touch this path, and stacking two of them creates bugs.
Minification. Irrelevant to JSON.

The maintenance habit that keeps it fast

Once an app depends on your API, one rule matters more than any optimization: plugin and PHP updates go to staging first. A plugin update that changes how product data serializes breaks your app as well as your site, and your app’s users report it in your App Store reviews rather than in your inbox. Cloudways includes free advanced staging and cloning, so there is no reason not to.

Then re-run the baseline curl once a month. Response time drifts upward as catalogs and plugin lists grow, and catching it at 600 ms is much easier than at 1.5 seconds.

Related reading

A native storefront renders instantly and then fills with your store’s data — so your API’s response time is, quite literally, how fast your app feels.