wp_options autoload: What It Does and What Is Safe to Change

You sorted wp_options by value size, and something near the top has autoload set to yes, or on if the row was written by WordPress 6.6 or later. Maybe Site Health told you your autoloaded options total 1.4 MB and left it at that. Either way you are now looking at a column with five possible values and no obvious rule for which one is right.

The autoload column is one of the few places in a WordPress database where a one-word change measurably affects every page load on the site. It is also one of the easiest places to make a site slower while believing you are making it faster.

What the autoload column actually does

On every request, before your theme renders anything, WordPress calls wp_load_alloptions(). That function runs a single query along these lines:

SELECT option_name, option_value FROM wp_options
WHERE autoload IN ('on','auto-on','auto','yes');

The whole result set goes into the object cache under the key alloptions. Every get_option() call for the rest of that request is then served from memory instead of the database.

That is the trade. Autoloaded options cost one query for all of them together. Non-autoloaded options cost one query each, on demand. Twenty small options read on every page belong in the autoloaded set. One 500 KB blob read on a single admin screen does not.

The five values, and what changed in WordPress 6.6

Before 6.6 the column held yes or no. WordPress 6.6 replaced that with five values so core could tell a developer’s explicit choice apart from its own automatic one.

That last row is the part almost every older tutorial gets wrong. The 6.6 upgrade did not rewrite your existing rows. There is no migration. Options written or updated since the upgrade carry the new values; everything untouched since 2024 still says yes or no. Any query you run has to cover both vocabularies or it will quietly report a fraction of the truth.

Since 6.6, an option written through add_option() or update_option() whose value exceeds 150,000 bytes, and which does not explicitly pass true for the $autoload parameter, is stored as auto-off. The threshold is filterable through wp_max_autoloaded_option_size.

Why the autoloaded set gets large

Three causes, in roughly the order we find them on client sites.

Transients with no expiry. set_transient() decides autoload from the expiration argument, not from the size of the value. Pass an expiration and the value is stored with autoload off. Pass nothing and it is autoloaded, permanently. A plugin that caches a large API response with no expiry has effectively added that response to every page load on your site.

Orphaned options from plugins you removed. Deactivating a plugin does not remove its options, and plenty of plugins skip cleanup even on uninstall. Those rows keep their old yes and keep loading on every request for years.

Genuinely large settings blobs. Page builders, form plugins and security plugins store serialized arrays that grow with use. Most of them were written before the 150 KB rule existed and set autoload explicitly, which means the rule never applies to them.

Find out what is actually autoloading

Start with the total. Run this against your database, changing the wp_ prefix if yours differs:

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

Then the offenders:

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

Both queries list all four autoloading values on purpose. A query that checks only autoload = 'yes' misses everything written since the 6.6 upgrade, and a query that checks only 'on' misses everything written before it.

If you would rather not touch SQL, WordPress ships a version of this check. Tools → Site Health → Status flags autoloaded options once the total passes 800,000 bytes, a limit filterable through site_status_autoloaded_options_size_limit. Treat it as a trigger to look, not a target to hit. Plenty of sites run happily above it, and some struggle well below it.

With WP-CLI, the total is one command:

wp option list --autoload=on --format=total_bytes

What to actually change

Work down your list of the 25 largest and put each row into one of three buckets.

1. You recognise it and it is read on every page. Leave it alone, however large it looks.
2. You recognise it and it is read on one admin screen or one template. Turn autoload off.
3. You do not recognise it and the plugin is long gone. It is an orphan. Take a backup, then delete the row.

Changing autoload does not change the stored value. With WP-CLI:

wp option set-autoload my_big_option off

Or in PHP, wp_set_option_autoload( 'my_big_option', false ).

Here is the caveat that turns this exercise negative for a lot of people. Switching autoload off on a small option that gets read on every request converts one shared query into an extra query per request, forever. You have not trimmed the site, you have added work to it. Below roughly 1 KB there is nothing worth reclaiming, and the risk of guessing wrong about how often something is read is real. Chase the top of the list and stop when the numbers get boring.

One last step people skip: flush the object cache afterwards. Redis or Memcached will happily keep serving the old alloptions entry, and you will conclude the change did nothing.

Where this fits with the rest of the database

Autoloaded options are one of four or five things that reliably make a WordPress database slow, and they are the cheapest to fix. The others are usually tables that grow without a cleanup routine: the Action Scheduler actions table when a scheduled job stops running, the Yoast indexables table on large content sites, and the logging tables that security plugins fill. We walk through the full sequence in our guide to WordPress database optimization.

If you would rather this were simply handled (monitored, cleaned and kept clean without you opening phpMyAdmin again), that is what our managed WordPress hosting covers.

Frequently asked questions