The autoload trap: WordPress's slowest hidden setting

If you run BoltAudit on a WordPress site that has been live for more than 18 months, there is a 60% chance the database layer flags wp_options autoload bloat as a contributing bottleneck. It is the most consistently underestimated performance problem in the WordPress ecosystem, and it is also the cheapest one to fix — usually a thirty-minute job that returns a measurable TTFB win on every page load.

This post is the deep-dive on what autoload is, why it matters, and how to fix it in a way that does not regress the moment a plugin update runs.

What autoload actually does

Every WordPress page load runs this query on bootstrap, regardless of caching, theme, or plugin layer:

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

The result is loaded into memory and made available via get_option() for the rest of the request. The point is to avoid hundreds of separate queries for individual options later in the request — and on a fresh WordPress install with 100 autoloaded rows totaling 200KB, that is exactly what happens. Fast, efficient, well-designed.

The trap is that plugins are allowed to add autoloaded options whenever they want, the framework provides no guardrails on size, and most plugins never clean up after themselves on uninstall. A site that has tried 30 plugins over three years can easily end up with 5–10MB of autoloaded data, much of it from plugins that were deactivated and deleted years ago.

Why a few extra MB matters

People dismiss this because "a few megabytes" sounds small in 2026. The cost is not the storage. The cost is:

1. The query takes longer. A 5MB result against an unindexed scan can take 80–200ms by itself.
2. PHP has to deserialize all of it. Most autoloaded options are PHP-serialized arrays. Unserializing 5MB of data takes another 30–60ms.
3. It runs on every uncached request. Page cache hides this from your team but exposes every cold-cache visitor and bot to the full penalty.
4. It runs even on AJAX and REST requests. Every WP-Admin AJAX call, every WC API call, every webhook handler pays this tax.

We commonly see 200–400ms of TTFB attributable to autoload alone on stores that have never cleaned it up.

The diagnostic queries

Run these against your database. You will need WP-CLI, phpMyAdmin, or any SQL access to the WordPress database.

Total autoload size

SELECT
  ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb,
  COUNT(*) AS row_count
FROM wp_options
WHERE autoload = 'yes';

What good looks like:

Total size	Verdict
under 256KB	Excellent. Do not touch.
256KB–1MB	Healthy.
1–3MB	Concerning. Worth a cleanup pass.
3–6MB	Real problem. Probably 100–300ms of TTFB.
over 6MB	Critical. Stop reading and clean it now.

Top 30 largest autoloaded options

SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

This is the high-value query. The largest 30 rows almost always account for 80% of the bloat. You will see things like:

• wpseo_taxonomy_meta weighing 800KB on a site that has had Yoast for years
• wf_pp_global_settings left behind by an uninstalled WooCommerce extension
• rewrite_rules at 200KB (this one is normal — do not touch it)
• auto_updater.lock and other transients accidentally autoloaded
• Old plugins' settings that should have been removed on uninstall

Orphaned plugin options

SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload = 'yes'
  AND option_name NOT LIKE 'wp\_%'
  AND option_name NOT LIKE 'theme\_%'
  AND option_name NOT LIKE 'rewrite\_%'
ORDER BY LENGTH(option_value) DESC
LIMIT 50;

Anything starting with a plugin's name (e.g., wpseo_, woocommerce_, elementor_) for a plugin you have uninstalled is orphaned bloat that should be removed.

The fix

The actual cleanup is in three buckets, from safest to riskiest.

Safe: orphaned options from uninstalled plugins

If option_name starts with the prefix of a plugin you no longer have installed, it is safe to delete. Use:

DELETE FROM wp_options WHERE option_name = 'name_from_query';

Always run this with WHERE option_name = 'specific_name' — never with a wildcard LIKE until you are absolutely sure.

Medium-risk: setting autoload to 'no' on rarely-read options

Some legitimate plugin options are autoloaded but only read on admin pages — they should not be in the autoload set at all. Common offenders are SEO plugin sitemap caches and analytics plugins' scheduled-task state. To flip without deleting:

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'option_name_here';

The plugin will still find the option via get_option() — it just won't be loaded into memory on every request. Worst case a single uncached get_option() adds a few milliseconds.

Risky: bulk cleanup of transients

Transients should expire and clean themselves up but, in practice, failed cron runs leave orphans. To find them:

SELECT option_name FROM wp_options
WHERE option_name LIKE '_transient_%'
   OR option_name LIKE '_site_transient_%'
LIMIT 100;

The safest path is the WP-CLI built-in:

wp transient delete --all

That clears everything via the proper API, including any in-memory cache, and it's plugin-aware.

Keeping it from regressing

Cleaning autoload once is a band-aid. The real fix is preventing regressions:

1. Audit wp_options size on every plugin install. A 30-second check after activating a new plugin catches the worst offenders.
2. Use the right uninstall hook. When you write a plugin, register a proper register_uninstall_hook that deletes its options. Most plugins do not. You can be the exception.
3. Set up a weekly check. A simple cron that emails the autoload size weekly catches creep before it becomes a problem.
4. Object cache helps but is not a fix. Redis-based object caching reduces the repeat cost of autoload, but the first request after a cache flush still pays the full price. The only fix is keeping autoload small.

What BoltAudit does

The database layer of every BoltAudit audit runs the queries above (and a dozen more) and tells you the exact autoload size, the top bloated rows, and the projected TTFB win from cleanup. If autoload is your bottleneck, the report includes the SQL ready to paste — so the fix is a copy-paste job once you have run the audit.

Run a free audit — find out if autoload is on your top-10 fix list before you spend an afternoon optimizing JavaScript that was never the real problem.