Slow WooCommerce Admin? Clean Up Autoloaded Options in wp_options

If your WooCommerce admin takes 5 to 15 seconds to load every screen, and the front end is slow even with page caching, the database is a likely cause. Specifically, a bloated wp_options table full of "autoloaded" data that WordPress loads into memory on every request. Here's how to measure it and fix it safely.

What autoloaded options are

The wp_options table stores settings for WordPress core, your theme and every plugin. Each row has an autoload flag. On every page load, front end and admin alike, WordPress runs one query that fetches all autoloaded rows into memory, whether that page needs them or not.

That's efficient when the total is small. It becomes a problem when plugins autoload big data like logs, cached API responses or stats, or leave rows behind after you uninstall them. A healthy site autoloads well under 1 MB. I regularly see stores autoloading 5 to 20 MB on every single request.

Recent versions of WordPress flag this in Tools → Site Health with a notice that autoloaded options could affect performance. If you see that notice, keep reading.

Step 1: Measure the total autoload size

Run these in phpMyAdmin, Adminer or wp db query. Replace wp_ if your table prefix is different. Since WordPress 6.6 the autoload column can hold several values (on, auto, auto-on), while older sites use yes. The query below covers all of them:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb,
       COUNT(*) AS autoload_rows
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Step 2: Find the biggest offenders

SELECT option_name,
       ROUND(LENGTH(option_value) / 1024, 1) AS size_kb,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

Usually a handful of rows make up most of the total. For each one, work out which plugin it belongs to. The prefix usually gives it away (wpseo_ is Yoast, _transient_ is temporary cache, rewrite_rules is core).

Step 3: Decide what to do with each row

Rows from plugins you no longer use

Uninstalled plugins often leave their options behind. If you're certain the plugin is gone for good, delete its rows:

DELETE FROM wp_options WHERE option_name LIKE 'oldplugin\_%';

Run a SELECT with the same WHERE clause first and check the list. A loose pattern can catch rows from other plugins with similar names.

Large rows that are needed, but not on every page

If a plugin is still active but its big option is only used on its own settings page, you can turn off autoloading for that row. The plugin will still load it when it needs it, just with one extra query.

-- WordPress 6.6 and newer
UPDATE wp_options SET autoload = 'off' WHERE option_name = 'some_large_option';

-- Older WordPress
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'some_large_option';

Test the plugin's features afterwards. Rarely, a badly written plugin assumes its option is always in memory.

Rows to leave alone

Don't turn off autoload for core options like siteurl, home, active_plugins, cron, rewrite_rules or wp_user_roles, or for your theme's main settings. They're needed on every request anyway.

A very large cron row (hundreds of KB) is a separate problem: thousands of scheduled events, usually from a plugin re-scheduling the same event over and over. Inspect it with wp cron event list.

Step 4: Clear expired transients

Transients are temporary cache entries. Without a persistent object cache they're stored in wp_options, and expired ones aren't always cleaned up. With WP-CLI:

wp transient delete --expired

Deleting all transients (wp transient delete --all) is also safe in principle, since plugins rebuild them on demand. Expect the first few page loads afterwards to be slower while caches warm up.

Step 5: Check the Action Scheduler tables

WooCommerce uses Action Scheduler for background jobs. Completed and failed actions pile up in wp_actionscheduler_actions and wp_actionscheduler_logs, and on busy stores these tables can grow to millions of rows.

SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;

WooCommerce cleans up completed actions after a retention period. If you see hundreds of thousands of failed or pending actions, something is wrong upstream: a webhook endpoint that keeps failing, or WP-Cron not running. My guide on fixing WP-Cron and stuck scheduled actions covers this. Review them under WooCommerce → Status → Scheduled Actions.

Step 6: Add a persistent object cache

After the cleanup, a persistent object cache (Redis or Memcached) keeps options and query results in memory between requests instead of fetching them from MySQL every time. Many managed hosts offer Redis with one click. Pair it with the Redis Object Cache plugin and the admin usually gets noticeably faster again.

An object cache doesn't replace the cleanup. It caches whatever you give it, including 15 MB of junk.

Step 7: Consider HPOS for large order volumes

High-Performance Order Storage (HPOS) moves orders out of wp_posts and wp_postmeta into dedicated tables, which makes order screens and queries much faster on stores with many orders. It's the default for new stores. Existing stores can enable it under WooCommerce → Settings → Advanced → Features once all their plugins are compatible. WooCommerce lists any incompatible plugins on that screen.

Measure again

Re-run the query from Step 1 and time a few admin screens. Getting autoload from several MB down to a few hundred KB, plus an object cache, is often the single biggest admin speed-up a store can get. The Query Monitor plugin is useful here: it shows the slowest database queries on each admin page, which helps when the remaining slowness comes from a specific plugin.