WooCommerce Slow Checkout and Admin: Causes and Fixes

A slow WooCommerce checkout or admin is almost always a server-side problem, not a front-end one. Checkout and wp-admin cannot be served from a page cache, so every request runs PHP and database queries, and that work grows with every order, plugin and scheduled task. Measure time to first byte first, then look at five suspects: hosting limits, a missing object cache, order storage, background tasks and plugins. Fix them in that order, one change at a time, on a staging copy.

Measure where the time goes

You cannot fix what you have not timed. Take these baselines before you touch anything:

1. Checkout page. In Chrome DevTools, open the Network tab, reload /checkout/ and read the Waiting for server response time (time to first byte) on the main document.
2. Checkout refresh. Change a field, such as the postcode. WooCommerce calls ?wc-ajax=update_order_review. If that request is slow, shipping or tax logic is the bottleneck.
3. Admin. Time the Orders screen and the Products list the same way.
4. Cart and a product page, so you know what a normal page costs on this server.

Write the numbers down with the date. They are your before and after.

Then install the Query Monitor plugin on a staging copy. It lists slow database queries, slow hooks and outgoing HTTP requests, and groups them by plugin or theme. Most mysteries end there.

Rule out hosting and caching mistakes

Check the basics before the clever fixes:

• PHP. Run a PHP version that is still supported, with OPcache enabled. WooCommerce publishes its server requirements, and older PHP is both slower and a security risk.
• Server limits. Each shopper uses a PHP worker while checkout runs. On entry-level shared plans, a handful of simultaneous checkouts can exhaust the allowance. If checkout time climbs with traffic, this is the cause.
• Page cache rules. Never page-cache the cart, checkout and My account pages. WooCommerce sets cookies such as woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_*, and your cache must skip requests that carry them. A cache that serves one shopper’s cart to another is a worse problem than a slow page.

Add a persistent object cache

Without one, WordPress repeats the same database lookups for options, products and other data on every request. A persistent object cache, usually Redis or Memcached, keeps the results between requests. It helps checkout and admin more than a page cache does, because they cannot use a page cache.

Your host has to provide the service, and a plugin or a drop-in object-cache.php connects WordPress to it. After installing, confirm it works. Query Monitor reports whether an external object cache is in use, and WordPress’s Site Health screen may recommend one if you lack it. If it is working, repeat your timings and note the difference.

Turn on High-Performance Order Storage

Older WooCommerce stored orders as posts with a lot of post meta, which is slow to query once you have many orders. High-Performance Order Storage (HPOS) puts orders in dedicated tables. It has been the default for new stores since WooCommerce 8.2. Older stores have to opt in, and many never did.

To check, go to WooCommerce, Settings, Advanced, Features, and look at Order data storage. If you are still on the posts storage:

1. Make a full backup and do this on staging first.
2. Check the plugin list on that screen. A plugin that is not compatible with HPOS has to be updated, replaced or removed before you switch.
3. Turn on compatibility mode, so orders are kept in sync between both storages while you test.
4. Place test orders, refund one, and check every plugin that touches orders: shipping labels, invoices, exports, subscriptions.
5. When everything passes, switch, and leave compatibility mode on for a while before turning it off.

Fix WP-Cron and the Action Scheduler backlog

WooCommerce runs a lot of background work through Action Scheduler: emails, webhooks, subscription renewals, analytics imports. That work is triggered by WP-Cron, which by default runs when someone loads a page. On a busy store that means shoppers can end up waiting for housekeeping.

Look at WooCommerce, Status, Scheduled Actions. Large counts of Pending, Past-due or Failed actions are a warning. Find which plugin created them, fix or remove it, and clear what is stale.

Then take cron off the shopper’s request. Turn off the page-load trigger in wp-config.php:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

And run due events from the server every minute instead. With WP-CLI available, the crontab line looks like this:

# crontab -e
* * * * * cd /path/to/site && wp cron event run --due-now >/dev/null 2>&1

On hosts without WP-CLI, the control panel’s cron tool can request wp-cron.php on the same schedule. Check your host’s documentation, and verify afterwards that scheduled actions are being processed. The WP-CLI reference covers the command.

Find the plugin or query that costs you

Query Monitor’s Queries by Component and Hooks panels tell you which plugin is spending the time. A few patterns come up again and again:

• A plugin that makes an outgoing HTTP request on every admin or checkout load, such as a license check or a live shipping quote.
• A plugin that runs a heavy query on every request instead of caching it.
• An options table full of autoloaded data. WordPress loads every autoloaded option on every request. Since WordPress 6.6, Site Health shows a critical warning when autoloaded options pass about 800 KB.

You can list the biggest autoloaded options with a read-only query (replace wp_ with your table prefix):

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;

Large entries usually belong to a plugin you removed long ago, or to one that stores caches in options. Do not delete rows by hand on a live store. Identify the owner, then remove it through the plugin or on staging with a backup.

Check what slows checkout itself

If update_order_review is slow, look at what runs when a field changes:

• Live carrier rates. Each change can trigger a request to a shipping API. Cache rates where the carrier allows it, and limit how often they are requested.
• Tax services. Automated tax lookups are a second outgoing request per update.
• Fraud and payment scripts that load before the shopper reaches the payment step.
• Cart fragments. On classic themes, the wc-cart-fragments script makes an AJAX call to refresh the mini cart on pages. Check the Network tab. If your theme has no mini cart, you can often dequeue it.
• Extra checkout fields and validators added by plugins, each with its own hooks.

A safe order of work

1. Take timings and a backup. Work on staging.
2. Fix hosting and cache rules.
3. Add a persistent object cache and re-time.
4. Move to HPOS if you are not on it.
5. Take cron off page loads and clear the Action Scheduler backlog.
6. Use Query Monitor to remove or replace the worst plugin.
7. Trim checkout calls, then re-time and compare with your first numbers.

If the store is also slow on the front end, the front end has its own causes. The Shopify mobile speed guide covers the front-end side, and much of it applies to WooCommerce themes too.

Before a big sale, the hosting and caching checks above are part of the Black Friday readiness checklist.

When to get help

Bring in a developer when the cause sits in custom plugin code, when the store has years of accumulated plugins that nobody wants to touch, or when the fix needs a migration of order data. Long-term WooCommerce maintenance is part of my work, and I audited a large WooCommerce build, its theme, plugins, hosting and integrations, for HotTub.com.

If your checkout or admin is slow, send me the store address and the symptoms. I will reply with what I think is causing it and what I would check first.