← All postsTechnical

Your store's speed is your app's speed

By · Published October 4, 2026 · 4 min read

Your store's speed is your app's speed
Photo: Duncan Oluwaseun / Pexels

Here is the sentence that explains most “the app feels slow” complaints: a native storefront renders instantly and then fills with your store’s data.

The first half is the app’s job. The second half is yours. Almost every performance conversation about a store app is really a conversation about which half someone is talking about.

The two halves, separated

The rendering half. Tapping a category pushes a screen that already exists — the layout is compiled into the app. You see structure immediately: a grid, headings, placeholders. This is why apps feel faster than websites even when the numbers are similar, and it is entirely a property of the app’s architecture. The mechanics.

The data half. The structure then fills from your WooCommerce REST API. If that takes 200 ms, the app is instant. If it takes 1.5 seconds, the customer looks at a well-designed skeleton for a second and a half — better than a blank browser, and still not fast.

Which means: you cannot buy your way out of a slow store with a good app, and a fast store cannot rescue a browser-based app. You need both halves.

The five measurements

Do these in order. Each one tells you something the previous one could not.

1. Your API’s response time, from outside your network.

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

Five runs, take the median. Under 300 ms is good; over 1.5 seconds is the thing to fix before anything else. This is the single most important number and almost nobody measures it, because no speed tool shows it. The full diagnostic.

2. The same request with a filter applied. Add a category and an attribute. Filtered catalog queries are the expensive ones and the most-used feature in a catalog app.

3. wp-admin load time. Never page-cached, so it is an honest reflection of your server. If editing a product takes four seconds, your PHP and database are the problem, and the front-end score you are proud of is measuring cached HTML.

4. Your image file sizes. Open a product gallery image directly and look at the kilobytes. If the app is downloading 3 MB files to fill 400 px tiles, the API was fast and the screen still took two seconds. Image sizing.

5. Time to first meaningful screen in the app, on a real phone, on mobile data — not office wifi. This is the number your customer experiences, and it is measurements 1 through 4 combined.

What to fix, in order of return

1. Turn on a persistent object cache. Redis or Memcached. The largest single improvement available to API traffic, because WordPress otherwise recomputes the same option and term data on every request. Frequently halves response times on an uncached store. Why it matters most.

2. Move to a current PHP 8.x. Materially faster than 7.4 for identical code. Test on staging, then switch.

3. Fix your image sizes. Compress on upload, confirm the intermediate sizes exist, and confirm the app is requesting them rather than originals.

4. Audit plugins for per-product overhead. Every plugin hooking product data filters runs once per product per response — twenty products a page means twenty executions. Deactivate on staging, one at a time, and re-measure.

5. Give the database RAM. If filtered queries are still slow after the above, your MySQL buffer pool is too small for your catalog.

6. Move the server closer to your customers. Latency is geography and no software fixes it. Hosting decisions.

7. Add PHP workers. Concurrency, not per-request speed. This is what fails during a push campaign’s opening burst.

Note what is not on that list: a CDN for the API (CDNs cache static assets; your API responses are dynamic), more page-cache plugins (they do not touch this path), and minification (irrelevant to JSON).

Two symptoms and what they mean

“The app is slow on launch but fine afterwards.” Concurrency. Several requests fire at once at launch; if you have two PHP workers, the third waits. Add workers, or add caching so each request is cheaper.

“The app is slow when I filter.” Database. Attribute filtering on a large catalog is genuinely expensive. RAM, indexes, and WooCommerce’s own lookup tables.

“Everything is uniformly a bit slow.” Either no object cache, or geography. Check the object cache first, because it is free and instant.

What to ask the app vendor about their half

The data half is yours; the rendering half is theirs, and it is fair to ask what they do while waiting for your store:

  1. What does a screen show while data is loading? The right answer is skeletons or placeholders with reserved space. A spinner is a worse answer, and a blank screen is the worst.
  2. Is the catalog cached on the device? Reopening the app to yesterday’s grid, which then refreshes, feels instant.
  3. Does going “back” refetch? It should not — the list should be there with its scroll position.
  4. Are images cached on disk and sized for the container?
  5. What happens when the store is unreachable? A designed state, not a browser error.

Good answers to those five mean the rendering half is done properly, and any remaining slowness is a measurement-1 problem.

The monthly habit

Run measurement 1 once a month and write the number down. Response times drift upward as catalogs and plugin lists grow, and catching it at 600 ms is much easier than at 1.5 seconds — by which point you are debugging six months of accumulated changes rather than last month’s plugin.

Related reading