Slow WooCommerce admin, cart and checkout? Look at the database

A WooCommerce store can pass a speed test on a product page and still feel slow where it matters: the order screens in the admin, the cart and the checkout. Images don't explain that. Those pages are built fresh for every visitor from database queries, so once the front end is tidy, the database and the dynamic pages are where we look next.

Why are cart and checkout slower than product pages?

Because they can't be served from a page cache. WooCommerce's caching guide says Cart, Checkout and My Account must stay out of the cache, because they show information specific to the current customer and their cart. Each shopper's cart lives in the database, so every visit runs PHP and queries from scratch.

So a page cache can make your catalogue fast and do nothing for checkout. Test those pages separately, and check that your host's server cache excludes them: WooCommerce notes that a cached My Account page can trap customers in a password reset loop.

Should we switch to High-Performance Order Storage?

Yes, once your extensions support it. High-Performance Order Storage (HPOS) moves orders out of the shared WordPress posts and postmeta tables into dedicated order tables with their own indexes. WooCommerce describes the result as fewer read and write operations and fewer busy tables. New installs use HPOS by default; older stores often still run on posts storage. We switch in this order:

1. Check compatibility. Under WooCommerce > Settings > Advanced > Features, the HPOS option stays disabled while an incompatible plugin is active, with a link to the plugins concerned. Update or replace those first.
2. Turn on compatibility mode. WooCommerce then syncs orders between the old and new tables, with background actions copying existing orders across.
3. Switch once the sync has finished and leave compatibility mode on for a while. If something breaks, you can switch back.
4. Clean up later. When HPOS is fully working, a WooCommerce status tool clears the old order data from the legacy tables.

What does a persistent object cache do for a store?

It keeps the results of repeated database work in memory between requests, helping the very pages a page cache can't touch. WordPress's built-in object cache only lasts for a single page load by default. A persistent backend such as Redis or Memcached, usually provided by the host and connected through a plugin, keeps that data for later requests, so options and transients come from memory instead of the database.

WooCommerce's system status report shows whether one is connected, under External Object Cache, and WordPress Site Health recommends one on production sites when it judges it worthwhile.

What is autoload, and why does it matter?

Autoloaded options are settings WordPress loads from the wp_options table on every request, whether the page needs them or not. Each plugin and theme decides which of its options autoload, and the WordPress docs suggest keeping the total under 800 KB. Large logs or settings blobs stored this way make every request heavier, checkout included.

Since WordPress 6.6, new options over 150,000 bytes are not autoloaded unless a plugin insists, and Site Health flags a total above 800 KB. Existing rows were not converted, so older stores keep what was saved before. This query lists the largest autoloaded rows:

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;

Your table prefix may differ. Rows left by removed plugins are common culprits: deactivation shouldn't delete a plugin's data, and deletion only cleans up if the plugin ships an uninstall routine. Take a backup, confirm the plugin is gone, then delete its rows or switch their autoload off.

What else builds up in the background?

Three things, each normal and each worth checking:

• Cart fragments. The wc-cart-fragments script uses admin-ajax to refresh the mini cart without reloading the page. Since WooCommerce 7.8 it no longer loads on every page, only where the cart widget renders or another script needs it, but some themes hard-code that widget into their templates. The Mini-Cart block doesn't use fragments at all.
• Action Scheduler. WooCommerce and many extensions queue background jobs in their own tables, listed under WooCommerce > Status > Scheduled Actions. A few past-due actions are normal; several more than a day old suggest something is wrong.
• Expired transients. Without an object cache they sit in wp_options, and WordPress clears them only infrequently. WooCommerce > Status > Tools has a Clear expired transients tool.

How do you measure before and after?

On the slow screens themselves, one change at a time:

• Query Monitor, a free plugin, flags slow, duplicate and failing database queries and groups them by the plugin, theme or core component responsible. Only administrators see its output, and it adds debugging data to Ajax responses too.
• The database slow query log records statements that run longer than a set time. In MySQL it is off by default, so ask your host to enable it for a few days.
• The WooCommerce system status report lists each database table with its data and index size, so an oversized wp_options or order table stands out.

Note timings for the orders screen, the cart and a test checkout, then repeat after each change.

Where to start

Open WooCommerce > Status, check the object cache line, table sizes and scheduled actions, then run the autoload query on a copy of the database. That shows which fix comes first. Our WordPress development service covers WooCommerce performance work, or start with a website review.