Speed up the WooCommerce backend: orders, scheduled actions and analytics

To speed up the WooCommerce backend, find which screen is slow and why, then fix the usual causes in order: orders still stored in the WordPress posts table instead of High-Performance Order Storage (HPOS), a backed-up Action Scheduler queue because WP-Cron does not run often enough, analytics imports and dashboard widgets, plugins that call outside services on every admin page, and a server that is too small for uncached work. The admin can never be served from a page cache, so it shows your server's real speed. This guide is for store owners and developers whose shop front is fine but whose orders screen takes ten seconds. It is part of the WooCommerce store checklist, where the admin is step 6.

Quick answer

• Measure first with the Query Monitor plugin on the slow screen: slow database queries, the plugin that made them, and outgoing HTTP calls.
• Use HPOS. Check WooCommerce → Settings → Advanced → Features. Order storage in dedicated tables makes order screens and searches faster on a big store.
• Fix the Action Scheduler queue. Thousands of past-due actions under Tools → Scheduled Actions mean WP-Cron is not keeping up; run it from a real server cron.
• Switch off what you do not use: WooCommerce Analytics, marketplace suggestions and plugin dashboard widgets.
• Find plugins that call home on every admin page, and remove or configure them.
• Check the server: PHP version, object cache and enough PHP workers.

Why the WooCommerce admin gets slow

The shop front is mostly cached pages. The admin is the opposite: every screen is built by PHP for the logged-in user, every active plugin loads, and many screens run heavy queries across orders, products and customers. A store with a few hundred orders hides a lot of inefficiency; one with 50,000 orders and 5,000 products with variations shows all of it.

The slowness also grows over time: order data piles up, scheduled jobs pile up, and each new extension adds its own admin notices, widgets and remote calls. Nobody notices one addition; together they turn a two-second screen into a twelve-second one.

Step 1: find out what is slow

Guessing wastes days. Measure one slow screen, such as the orders list or the product editor.

1. Install and activate Query Monitor from wordpress.org. On a busy store, do this on a staging copy with the same data, or on production for a short time.
2. Open the slow screen. The Query Monitor bar in the admin toolbar shows the page generation time, the number of database queries and their total time.
3. Open Queries by Component to see which plugin or theme made the slowest queries, and Slow Queries for the worst ones.
4. Open HTTP API Calls to see outgoing requests made while the page was built, with their duration. A licence check or a marketplace feed that takes 3 seconds shows up here by name.
5. Compare with the same screen after deactivating a suspect plugin on staging.

Also look at the server: if even an empty admin page, such as Settings → General, takes more than a second or two, the problem is the hosting plan or PHP set-up, not WooCommerce.

Step 2: move orders to High-Performance Order Storage

For years WooCommerce stored orders as WordPress posts, with every order detail as a row in wp_postmeta. On a large store that table grows to millions of rows shared with every other post type, and order screens, searches and reports slow down.

High-Performance Order Storage (HPOS) stores orders in their own tables (wc_orders, wc_order_addresses, wc_order_operational_data and wc_orders_meta) with indexes designed for order queries. WooCommerce's documentation says it has been enabled by default for new installations since WooCommerce 8.2, released in October 2023. Stores created before that may still use the posts tables.

To check and switch:

1. Go to WooCommerce → Settings → Advanced → Features and look at Order data storage.
2. If it says "WordPress posts storage", check the list of incompatible plugins WooCommerce shows on that screen. Update or replace those first.
3. On a staging copy, turn on Enable compatibility mode (synchronisation), wait until WooCommerce has copied every order to the new tables, or run wp wc hpos sync for a large store, then switch storage to High-performance order storage.
4. Test orders, refunds, subscriptions and every extension that touches orders. Then repeat on production.
5. Once everything works, turn compatibility mode off. Keeping two copies of every order in sync costs writes on every order change.

On stores with an object cache, recent WooCommerce versions also offer HPOS Data Caching on the same Features screen, which caches order data between requests.

Step 3: clear the Action Scheduler queue

WooCommerce runs background work through the Action Scheduler: sending webhooks, updating analytics, processing subscriptions, syncing stock, cleaning up sessions. Many extensions use it too. You can see the queue under Tools → Scheduled Actions (also linked from WooCommerce → Status).

What to look for:

• Hundreds or thousands of "Pending" actions that are past due. The queue is not being processed fast enough. By default it runs from WP-Cron, which only fires when someone visits the site, and a busy admin can end up doing that work during your own page loads.
• Many "Failed" actions for the same hook. A plugin keeps failing, and often retries. The hook name tells you which plugin; fix or remove it.
• Very large tables. By default, completed and cancelled actions are removed after 30 days. Stores with heavy traffic can still have millions of rows in the actionscheduler_actions and actionscheduler_logs tables.

The fix for the first one is a real server cron, so scheduled work runs every minute in the background, not during page loads. In wp-config.php:

// wp-config.php: stop WP-Cron from running on page loads
define( 'DISABLE_WP_CRON', true );

Then add a cron job in your hosting panel or crontab that runs every minute:

* * * * * cd /var/www/example && wp cron event run --due-now --quiet

WP-Cron and scheduled tasks covers the set-up on common hosts. To work through a large backlog once, wp action-scheduler run processes the queue from the command line.

Step 4: switch off analytics and admin extras you do not use

• WooCommerce Analytics keeps its own report tables up to date in the background and runs its dashboard queries on the WooCommerce home and Analytics screens. If you use another reporting tool, turn it off under WooCommerce → Settings → Advanced → Features → WooCommerce Analytics. If you do use it, let the initial import finish before judging speed.
• Marketplace suggestions and extension promotions add remote content to admin screens. WooCommerce → Settings → Advanced → WooCommerce.com has a setting to stop showing suggestions.
• Dashboard widgets from plugins often run their own queries or remote calls on the main Dashboard. Hide the ones you do not need under Screen Options, or remove the plugin.
• Admin notices from many extensions each run code on every screen. A plugin that shows a notice you always dismiss is still doing work.

Step 5: find plugins that call home or query too much

Query Monitor's HTTP API Calls panel is the quickest way to find a plugin that checks its licence, fetches news or pulls a remote feed on every admin page load. A healthy admin page makes few or no outgoing calls; if you see several on every screen, look for a setting to cache them or switch them off, or ask the vendor.

Queries by Component shows plugins that run heavy queries on screens where they are not needed, such as a reporting plugin adding columns to the orders list. The WordPress Heartbeat API also sends regular requests from open admin tabs; product and order editors need it for autosave and edit locks, so do not switch it off completely, but close admin tabs you are not using.

Step 6: clean up the database

• Autoloaded options. WordPress loads every autoloaded option on every request. Tools → Site Health warns when their total size passes 800 KB. Old plugins often leave large autoloaded options behind; delete what belongs to plugins you removed.
• Sessions and transients. WooCommerce stores shopper sessions in wp_woocommerce_sessions and removes expired ones in a scheduled task, another reason scheduled work must run reliably. Expired transients are cleaned the same way.
• Product revisions and variations. Products with hundreds of variations are slow to edit and save. Delete variations you no longer sell, and limit revisions with define( 'WP_POST_REVISIONS', 10 ); in wp-config.php.

Take a backup before any database clean-up, and prefer WooCommerce's own tools under WooCommerce → Status → Tools to raw SQL.

Step 7: give the admin enough server

Admin work is uncached PHP and database work, often with several staff members and background jobs at once. The things that help the checkout help the admin too:

• A current PHP version (WooCommerce recommends 8.3 or newer).
• A persistent object cache, Redis or Memcached, which also enables HPOS data caching.
• Enough PHP workers for staff, shoppers and background jobs at your busiest hour.
• A database server that is not shared with hundreds of other sites.

getReport measures the public side of the server, not the admin, but a slow uncached Time to First Byte on the shop front points to the same limit. The WordPress Doctor also compares your server's TTFB with other getReport-tested sites on the same host, once enough sites on it have been tested:

If the plan is the limit, WooCommerce hosting shows how to test candidate hosts with a copy of your store.

Common mistakes

• Optimising the shop front for an admin problem. Caching plugins and image optimisation do nothing for the orders screen. Measure the admin itself.
• Switching to HPOS on production first. Test on staging with your real extensions; some older extensions still read orders from the posts table.
• Leaving compatibility mode on forever. It doubles the writes for every order. Turn it off when everything works.
• Deleting the Action Scheduler tables. They hold pending work, such as subscription renewals. Fix the cause of failed actions and let the cleaner remove old ones.
• Installing a "speed up admin" plugin. It adds one more plugin to every admin page. Remove what is slow instead.

Questions people ask

Why is my WooCommerce admin so slow?

Because every admin screen is built without a cache, with every plugin loaded and often heavy queries across orders and products. The usual causes are orders still stored in the posts table instead of High-Performance Order Storage, a backed-up Action Scheduler queue, analytics and dashboard widgets, plugins that call outside services on every page, and a small hosting plan. Query Monitor shows which one applies.

What are scheduled actions in WooCommerce, and can I delete them?

Scheduled actions are background jobs in WooCommerce's Action Scheduler: webhooks, analytics updates, subscription renewals, stock syncs and clean-ups. Do not delete pending ones, because they are work still to be done. Completed and cancelled actions are removed automatically after 30 days by default. Many failed actions point to a failing plugin; fix or remove that plugin rather than deleting its history.

How do I check if my store uses HPOS?

Go to WooCommerce → Settings → Advanced → Features and look at Order data storage. "High-performance order storage" means HPOS is active; "WordPress posts storage" means orders still live in the posts table. New stores use HPOS by default since WooCommerce 8.2. Before switching an older store, check the incompatible plugins WooCommerce lists on that screen and test on staging.

Does disabling WooCommerce Analytics speed up the admin?

It can, if you do not use it. Analytics keeps its own report tables updated in the background and runs report queries on the WooCommerce home and Analytics screens. If you report elsewhere, switch it off under WooCommerce → Settings → Advanced → Features. If you rely on it, keep it on, make sure the Action Scheduler queue runs, and let the initial import finish.

Why is the WooCommerce orders page slow to load?

On a large store, the orders list queries thousands of orders with their meta data. With orders in the posts table, those queries share a huge wp_postmeta table with everything else. Moving to High-Performance Order Storage, showing fewer orders per page under Screen Options, and removing plugins that add extra columns or queries to the list usually make the biggest difference.