Why the WooCommerce orders screen got slow, and what actually fixed it

12 June 2026

A shop with roughly 90k orders started taking eleven seconds to open the orders list in wp-admin. Nothing had been deployed that week, which is usually the sign that the problem has been growing for months and finally crossed a threshold.

What it was not

The first three guesses were all wrong, so they are worth writing down:

It was not the server. Load average was under 1, disk was idle.
It was not a plugin doing something silly on admin_init. Disabling everything except WooCommerce changed the time by about half a second.
It was not the object cache. Turning it off made things worse, as expected, but the shape of the problem stayed identical.

Finding the actual query

The fastest way in is the slow query log with a threshold low enough to be rude:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = 'ON';

Reload the screen once, then turn it back off. One query dominated: a count over the orders table joined to the meta table, filtered by status, ordered by date. The count is what hurts — the list itself is paginated, but the pagination widget wants a total, and the total scans everything the filter touches.

The fix that worked

Three things, in order of how much they helped.

1. Turn on high performance order storage

The custom order tables move orders out of wp_posts and wp_postmeta into their own schema with real columns and real indexes. On this shop it cut the screen from eleven seconds to about two. Migration ran for forty minutes on 90k orders and can run while the shop is live, but do it during a quiet window anyway and take a dump first.

2. Stop counting exactly

The remaining two seconds were still the count. Nobody needs to know there are exactly 41,238 completed orders on page one. Filtering the admin query to skip the exact count and fall back to an approximate total removed most of what was left.

3. Clean the meta table

An abandoned plugin had been writing a row per order per page view since 2021. Six million rows of meta nobody read.

SELECT meta_key, COUNT(*) AS rows_used
FROM wp_postmeta
GROUP BY meta_key
ORDER BY rows_used DESC
LIMIT 25;

That query takes a while on a big table and is worth every second. Run it on a copy if the shop is busy. Deleting in batches of 5,000 with a short sleep between batches kept replication lag flat.

What I would do differently

Check the meta table first. It takes one query and it is the most common cause by a wide margin. The order storage migration is the bigger win, but it is also the bigger change, and on a smaller shop the meta cleanup alone would have been enough.