WordPress Autoloaded Options: Find and Fix wp

Your WordPress site feels slow, and you’ve already done the obvious stuff. Caching plugin? Installed. Images compressed? Done. Yet pages still take a beat too long to start rendering. There’s a decent chance the culprit is hiding somewhere most speed guides never look: the wp_options table in your database.

Here’s the short version. On a typical request, WordPress loads every autoloaded option into memory as one batch, using the persistent object cache when available and querying wp_options on a cache miss. That’s by design. The problem is that plugins you deleted years ago can leave rows behind, still flagged to autoload, so WordPress keeps hauling that dead weight into memory.

In this guide you’ll learn what autoloaded options actually are, how to measure yours with two safe, read-only SQL queries, which options are safe to flip, which ones you should never touch, and what kind of speedup you can honestly expect. Let’s open the hood. 🔧

What are autoloaded options, exactly? ⚙️

The wp_options table is WordPress’s settings drawer. Each row has a name (option_name), a value (option_value), and an autoload flag. When that flag is on, WordPress loads the row into memory at startup on every single request, all autoloaded rows in one query. The core team built it this way because fetching everything at once is faster than running separate queries for your site title, active plugins, timezone, and the rest. The official developer note on the Options API changes calls this technique “autoloading” and admits the default behavior led to many options being loaded on every page unnecessarily.

Since WordPress 6.6, the autoload column can hold more than the classic yes and no. New values like on, off, auto, auto-on, and auto-off let WordPress decide dynamically whether an option deserves the preload treatment. The old yes/no values still work and behave like on/off. Two more guardrails arrived in the same release: options larger than 150,000 bytes no longer get autoloaded by default, and Site Health (Tools → Site Health) now raises a critical warning, “Autoloaded options could affect performance,” once your autoloaded total passes 800 KB.

So where does the bloat come from? Mostly uninstall residue. You try a plugin, delete it, and its settings rows stay in wp_options with autoload still on. Some plugins also stash things that were never meant to load everywhere: debug logs, cached API responses, giant serialized arrays. Repeat that cycle for a few years on an active site and the autoload pile grows from kilobytes into megabytes.

Before anything else: back up your database

⚠️ WARNING: Take a full database backup before you change anything in wp_options. A wrong edit here can white-screen your site or lock you out of wp-admin. Most hosts offer one-click backups, and phpMyAdmin’s Export tab works too. If you have a staging site, practice there first.

To be clear about the risk levels: the SELECT queries below only read data, so they’re completely safe to run. The UPDATE and DELETE statements near the end are the part where the backup matters. Don’t skip it. 💾

Step 1: Check how much data WordPress autoloads

Open your hosting control panel and launch phpMyAdmin (on cPanel or Plesk it’s usually right on the main dashboard; managed hosts have an equivalent database tool). Pick your site’s database in the left sidebar, then click the SQL tab and paste this:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoloaded_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Hit Go and you’ll get one number: the total size of everything WordPress preloads on every page load, in kilobytes. The IN list covers all four values that current WordPress counts as autoloaded (that’s exactly what the core function wp_autoload_values_to_autoload() returns, per the Options API reference). If your site runs something older than WordPress 6.6, a plain WHERE autoload = 'yes' is enough.

One gotcha: if your wp-config.php sets a custom $table_prefix, swap wp_options for your actual table name, like abc123_options.

Here’s a real result from a nearly fresh WordPress 7.0.2 test install: 69 KB total, spread across 133 autoloaded rows:

Terminal showing three SQL queries on a local WordPress 7.0.2 database: 133 autoloaded rows totaling 69 KB, with rewrite_rules as the largest option at 33542 bytes

How do you judge your number? If it’s anywhere near or above 800 KB, WordPress itself considers it a critical issue in Site Health. A lean site in the low hundreds of kilobytes (or less, like the test install above) has little to gain here. The sites that win big are the old ones with years of plugin churn, where the total quietly climbed into the megabytes.

Not a fan of SQL? Install the free Performance Lab plugin, built by the official WordPress Performance Team. It upgrades the Site Health check with a table of your autoloaded options, so you can review and disable the ones you don’t need straight from wp-admin, no queries required. 🔍

Step 2: Find the biggest offenders

If your total looked chunky, the next query shows which options eat the most space. Same SQL tab, same deal:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 10;

Reading the results is easier than it looks, because option names usually carry a prefix naming their owner. In the screenshot above, rewrite_rules tops the list at around 33 KB. That’s core WordPress (it maps your pretty URLs to content) and it belongs there, so leave it alone. The _transient_ rows are temporary cached data, and the trp_ entries belong to an installed translation plugin.

What you’re hunting for instead:

Prefixes from plugins you uninstalled ages ago. If the plugin is gone, its rows are pure ballast. Prime cleanup candidates.
Huge values from active plugins that don’t need to load everywhere. An import tool’s settings or a backup plugin’s log have no business loading on your homepage.
A pile of stale transients. Rows starting with _transient_ are supposed to expire, but the expired ones can linger in the table.

Step 3: Flip the safe ones to ‘no’ (or delete the dead ones)

Two situations, two different moves:

The option belongs to a plugin you still use, but it’s only needed on admin screens (importers, backup configs, analytics dashboards). Flip its autoload off. The data stays intact; WordPress just stops preloading it. Worst case, that one option costs a single extra query on the screens that actually use it. Fully reversible.
The option belongs to a plugin you deleted. Don’t bother flipping it. Delete the row entirely. First double-check on the Plugins screen that the plugin is really gone, and confirm the prefix matches its name.

To flip one option, the statement looks like this:

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

⚠️ CAUTION: Work one row at a time and always match the full, exact option_name. Never use LIKE wildcards in an UPDATE or DELETE on this table; one sloppy pattern can rewrite hundreds of rows. Reload your site after each change. To undo a flip, run the same statement with 'yes' instead of 'no'.

And to remove a row from a plugin that’s definitely gone:

DELETE FROM wp_options WHERE option_name = 'long_gone_plugin_settings';

For the transient pile, hand-cleaning is tedious. Deleting _transient_ rows is generally safe because WordPress rebuilds them, but a cleanup plugin such as WP-Optimize purges the expired ones in one click, which beats eyeballing hundreds of rows. 🧹

Options you should never touch 🚫

Some rows in wp_options are load-bearing. Flipping or deleting them won’t speed anything up; it will break your site. Keep away from:

siteurl and home: your site’s address. Change these and every page breaks.
active_plugins: the list of running plugins. Corrupt it and you can deactivate everything at once, sometimes with a white screen as a bonus.
wp_user_roles: the permission system. Damage it and you can lock yourself out of wp-admin.
cron, rewrite_rules, template, stylesheet: scheduling, URL routing, and your active theme. All core, all needed on every page.
Anything you can’t confidently tie to a specific plugin, theme, or core feature. Unknown name? Leave it.

One more rule: never hand-edit a serialized option_value. Those values look like a:3:{s:4:"name";...}, and every number in there is a character count. Change one character without updating the counts and the whole value corrupts. If you need to edit a value, use the plugin’s own settings screen.

A good rule of thumb: when in doubt, flip autoload instead of deleting. When still in doubt, leave the row alone. A few extra kilobytes never hurt anyone; a missing core option definitely will.

What kind of speedup should you expect?

Honest answer: it depends on how bad the bloat is. If your autoloaded total sits in the low hundreds of kilobytes, trimming it saves milliseconds you’ll struggle to notice. On an old, plugin-heavy site autoloading megabytes of junk, the win is real, because it applies to every request that boots WordPress: the frontend, wp-admin, and AJAX calls alike. Admin screens in particular can’t be papered over with page caching, so a leaner autoload pile makes the whole dashboard snappier too.

What this fix won’t do is just as important. Autoload cleanup does nothing for render-blocking JavaScript, oversized images, unoptimized fonts, or a slow host. If your bottleneck lives on the front end (and it often does), start with these five quick wins to speed up WordPress first, then come back here for the database hygiene.

Think of it like cleaning out a junk drawer: satisfying, occasionally eye-opening, and worth doing after any big plugin clear-out. Just don’t expect it to fix a problem that was never in the drawer. 😄

Wrapping things up

Autoloaded options are one of those invisible taxes on every page load, and now you know how to audit yours:

✅ Back up the database before touching anything.
✅ Measure your autoload total with one safe SELECT (or the Performance Lab plugin).
✅ List the biggest rows and identify them by prefix.
✅ Flip admin-only options to 'no'; delete rows from plugins you’ve uninstalled.
✅ Never touch core options like siteurl, active_plugins, or wp_user_roles.

Have you checked your autoloaded size yet? What number did you find, and did anything surprising show up in your top ten? Let us know in the comments below! 🎉