WooCommerce · order screens · admin side
Page caching serves your customers a file that was built earlier. Your staff get a page built from scratch, every time, on top of tables shared with every post and every product. That is why the orders list crawls while the shop itself feels fine.
No credentials. No server access. Order and product screens are measured separately.
Because the orders screen is the one page nothing can cache. It is per-user, always current, and it reads live data. Every plugin that hooks into the admin runs with it, and on most stores it queries tables that were never designed for order volume.
None of this shows up in a front-end speed score. Those tools measure the cached, logged-out shop, which is the one page that is already fine.
We said your shop is fast for customers. That is true of the pages a cache can serve. It is not true of the rest, and the rest is where the money changes hands.
Some pages are excluded from page caching deliberately, because a cached copy would be wrong:
This is the part a caching plugin does not fix. WP Rocket, LiteSpeed and the rest do exactly what they promise, and they do it well: they serve a prebuilt file to a logged-out visitor. The cart, the checkout and the add-to-cart call are outside that by design. Their speed comes from what happens on the server during the request, and no cache can change it.
That is why a shop can score well on a speed test and still lose sales at the checkout. The thing being measured is not the thing that is slow.
This is the argument that matters in a shop, because the time is somebody's paid hours. Put in your own numbers.
Waiting, every year, before anyone has done any work.
A shop owner can argue with a speed score. Nobody argues with their own payroll. That is why we measure the orders screen separately from the rest of the admin, and why the fix proposal always states what the number was before and what it is after.
WooCommerce used to keep every order in the same tables as your posts and pages. It now has dedicated order tables, called High-Performance Order Storage. Since October 2023 they are the default for new shops.
Existing shops were never moved, and there is no deadline. WooCommerce documents the migration as optional and keeps the old storage available. So a shop opened before late 2023 is very likely still reading orders out of tables shared with every draft, every revision and every product.
| Orders screen | Legacy post tables | Dedicated order tables |
|---|---|---|
| Where an order lives | Split across two shared tables, one row per field | A few purpose-built tables, one row per order |
| Filtering and searching | Joins across shared metadata | Indexed columns built for it |
| Competing with | Every post, page, product and revision on the site | Nothing else |
| Your shop, if opened before Oct 2023 | Almost certainly this one | Only if somebody migrated it deliberately |
An incompatible extension can break order handling, and that is not a risk worth taking for a faster screen. So it is never automated and never done straight on a live shop. We check every extension for compatibility, run the migration on a copy, measure both storages with the same tool, and only then move production, with the old storage still there to fall back to.
If the compatibility review says no, we say no. A slow orders screen is survivable. A broken one is not.
The free measurement tells you which storage your shop is on, how long your order and product screens actually take, and how deep the background queue is. That is the whole question answered in two minutes, without giving anyone access.
The measurement reads only and changes nothing. It is inert until you press the button. Any fix is agreed first, tested on a copy, and scheduled outside your busy hours.
Usually the combination is, not one of them. The measurement names which one takes the time on which screen, which is a different question from which one you could live without. We answer the first and let you decide the second.
Often both. A server can be healthy while a single admin screen runs hundreds of queries. The measurement separates the two, and where the evidence points at the server we say so and tell you what to ask for.
It is safe when it is done properly and dangerous when it is rushed. That means an extension compatibility review first, a run on a copy, measurements on both storages, and the old storage kept available afterwards.
The cached pages are not ours to speed up, and a caching plugin already handles those well. The cart, the checkout and the add-to-cart calls are a different matter: they cannot be cached, they run the same code as the admin side, and they are part of this work. So the answer is yes for the pages that decide whether an order completes, and no for the ones a cache already serves.
Install the plugin, press one button, and you will know how long your orders screen takes, which extension is taking the time, and which storage your orders are on.
No account, no credentials, no obligation.
The measurement tells you the numbers. The written audit tells you what they mean: which extension to deal with first, what is safe to change on a live shop, what is not worth touching, and in which order to act. A fixed scope at $450, and if you go on to order fixes worth more than $1,150, the audit fee comes off that invoice.
We check your measurement first. If it does not name at least three specific causes, you are not charged.