Every WordPress request loads your autoloaded options into memory before anything else happens. On a healthy install that's a few hundred kilobytes. On a neglected install, it can be tens of megabytes — mostly leftover plugin meta, abandoned settings, and accidental large values. Here's how to find what shouldn't be there and clean it up.
Update (January 2025): WordPress 6.6 (June 2024) and 6.7 (November 2024) introduced significant changes to how the Options API handles autoloading, including new autoload values ('on', 'off', 'auto', 'auto-on', 'auto-off') and a default 150 KB size threshold above which newly-added options no longer autoload. The SQL queries below were correct as of 2023 but will silently miss any options stored with the new values. For the modern picture, see WordPress 6.7 fixed (some of) the autoload problem.
WordPress has a quiet performance problem that almost no plugin will warn you about. Every request, before anything else runs, WordPress loads your wp_options rows where autoload = 'yes' into memory. On a clean install that’s maybe 200 KB. On a five-year-old site with a history of plugins installed, used briefly, and uninstalled imperfectly, it can be ten to fifty megabytes. The site gets slower in a way that doesn’t show up in any single page audit, because every page pays the same tax.
How autoloading actually works.
The wp_options table has three columns that matter: option_name, option_value, and autoload. When autoload is set to 'yes', the option is loaded on every WordPress request, regardless of which page is being served, and cached in PHP’s object cache for the duration of the request. This is great for things you actually need on every page: the site URL, the active theme, common settings. It’s catastrophic for things you don’t: cached API responses, old plugin debug logs, abandoned settings from plugins you uninstalled three years ago.
The fundamental problem: most plugins create autoloaded options on activation and don’t clean them up on uninstall. WordPress core doesn’t enforce a maintenance policy on this. Multiply by a few dozen plugin lifecycles and the autoload table becomes the largest single contributor to your time-to-first-byte.
How to audit your autoload table.
You don’t need a plugin for this. A single SQL query will tell you what’s in there:
SELECT
option_name,
LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 50;Run that against your database and you’ll usually see a familiar pattern: a handful of legitimate large entries (your active theme’s settings, your SEO plugin’s config), then a long tail of suspicious-looking entries with megabyte-scale values. The names are usually a tell: anything matching %_transient_%, %_cache, %log%, or referencing plugins you don’t recognize is a candidate for removal.
While you’re in there, get the total:
SELECT
ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';Anything under 1 MB is healthy. 1–5 MB is worth a look. 5–15 MB is a real problem. Above 15 MB, the site is paying a measurable latency cost on every request, and you’ll feel it on cold caches especially.
What’s safe to remove.
A few categories that are almost always safe to delete or flip to autoload = 'no':
- Transients that didn’t expire properly. Anything starting with
_transient_or_site_transient_with an old timestamp. These should expire on their own; when they don’t, they linger forever. - Plugin settings from uninstalled plugins. If you see options prefixed with a plugin slug for a plugin no longer installed, those are leftover. WP doesn’t clean them up by default.
- Debug logs stored in options. Some plugins store debug output in the options table. Those should never have been autoloaded; they exist for forensic purposes if they exist at all.
- Cached API responses. If a plugin caches external API data, that cache should be a transient with an expiry, not an autoloaded option. When you see one, fix it.
Two categories to be careful with: anything from your active theme (the theme might depend on options being autoloaded), and anything from a security plugin (some store rate-limit state that does need to be hot). When in doubt, flip the option to autoload = 'no' rather than deleting it — if something breaks, it’s recoverable.
What to do once it’s cleaned.
The cleanup is a one-time win. Without changes to the plugins on the site, the table will start growing again. Two ways to keep it healthy:
- Audit on a schedule. Quarterly is reasonable for a stable site. Monthly if you’re installing and removing plugins frequently. The query above takes 30 seconds to run.
- Be picky about plugin choices. Plugins that aggressively use autoloaded options for things that don’t need it are a long-term cost. When evaluating a new plugin, install it on a staging site and check whether it adds large autoloaded entries. If it does, that’s a sign of low engineering hygiene — consider an alternative.
This is the kind of maintenance that doesn’t get reported up the chain because there’s nothing dramatic to show for it. The site just stays fast. That’s the whole point. For sites already deep into legacy modernization work, the autoload audit is usually one of the cheapest wins on the list.
Performance problems like this are exactly what a Technical SEO engagement diagnoses and fixes at the source, before they quietly drag down rankings.