WordPress Autoloaded Options: The Silent Killer of Your WooCommerce Store

The Problem Nobody Sees

WordPress has a central table: wp_options. It stores site settings, plugin options, widget data, and transients. When an option is marked autoload = yes, WordPress loads it into memory on every request - every page view, every admin-ajax call, every API request. If you’re also experiencing slowness in the WooCommerce back-office, migrating to HPOS (High-Performance Order Storage) complements this cleanup work.

On a fresh WordPress install, autoloaded options weigh a few dozen KB. After two years of running a WooCommerce store with 30 plugins, it’s often 3 to 10 MB.

On every page load, WordPress runs this query:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

If the result weighs 5 MB, every page starts by loading 5 MB of data into memory. Before displaying anything.

How It Happens

Three main causes:

1. Uninstalled plugins that leave their data behind. You install a plugin, test it, deactivate and delete it. But its options stay in wp_options with autoload = yes. Multiply that by 20 plugins tested over two years, and you have hundreds of KB of orphaned data loaded on every page.

2. Transients that pile up. WordPress uses transients to store temporary data. When a transient expires, it isn’t automatically deleted - it stays in wp_options until someone requests it again. On an active WooCommerce, product cache transients, sessions, and price calculations pile up.

3. Plugins that abuse autoload. Some plugins store large amounts of data with autoload = yes when they only need it on certain pages. A stats plugin storing its logs in autoload, a translation plugin loading all strings into memory - it’s waste.

Since WordPress 6.6, the default behavior has changed: the $autoload parameter now defaults to null, letting WordPress decide intelligently. But this doesn’t fix options already in place (source: felix-arntz.me).

Diagnosing

Measure Total Weight

Connect to your database (phpMyAdmin, Adminer, or WP CLI) and run:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb
FROM wp_options
WHERE autoload = 'yes';

Interpretation:

• Under 800 KB: normal, no issue
• 800 KB to 1 MB: worth monitoring
• Over 1 MB: cleanup needed
• Over 3 MB: probably one of your site’s biggest bottlenecks

These thresholds are confirmed by Kinsta (source: kinsta.com) and Pantheon (source: docs.pantheon.io).

Identify the Biggest Offenders

SELECT option_name, LENGTH(option_value) / 1024 AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

You’ll probably see names like _transient_*, _site_transient_*, options from plugins you no longer use, or serialized theme data (Elementor or Divi options alone can weigh 500 KB+).

With WP CLI

If you have WP CLI (and you should), it’s even faster:

wp option list --autoload=on --format=table \
  --fields=option_name,size_bytes \
  --orderby=size_bytes --order=DESC | head -20

Cleaning Up

1. Delete Expired Transients

This is quick win number one. Zero risk, immediate impact:

wp transient delete --expired

Or in SQL:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

2. Disable Autoload on Unused Options

If a plugin is no longer active but its options are still autoloaded:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name LIKE 'plugin_name_%';

Caution: don’t change autoload on WordPress core or WooCommerce core options without knowing what you’re doing.

3. Use a Dedicated Tool

AAA Option Optimizer identifies autoloaded options that can safely be switched to no. It analyzes which options are actually used on each page and suggests changes.

WP Optimize includes a database cleaner that removes transients, revisions, and orphaned data.

4. Add an Index (Large Catalogs)

On sites with many options, adding an index on the autoload column speeds up the loading query:

ALTER TABLE wp_options ADD INDEX autoload_idx (autoload);

This is a recommendation from WordPress VIP (source: docs.wpvip.com) for high-traffic sites.

Real-World Impact

On a WooCommerce store I optimized, autoloaded options weighed 4.2 MB. After cleanup (expired transients, uninstalled plugin options, orphaned theme data), we got down to 620 KB.

The result: TTFB reduced by ~150ms on every page. It may not sound like much, but that’s 150ms saved on every request, compounding with gains from other optimizations.

And most importantly: this problem comes back. Without regular maintenance, autoloaded options re-accumulate. A quarterly cleanup is good practice.

Why Cache Doesn’t Fix This

A cache plugin stores the final HTML and serves it without running PHP. But WooCommerce’s dynamic pages (cart, checkout, customer account) aren’t cached. And every admin-ajax request (cart fragments, product search, shipping calculation) loads autoloaded options into memory.

Fast cache + 5 MB of autoloaded options = a fast site for static pages, but slow for everything interactive. That’s why cleaning the database complements cache - it doesn’t replace it. To understand exactly why cache plugins are not enough for WooCommerce, I explain the logical order of optimizations in detail.

Before starting this cleanup, I recommend running a WooCommerce performance audit to measure the actual state of your database and prioritize actions.

Don’t know how heavy your autoloaded options are? Request a free audit - it’s one of the first things I check.