WordPress Autoloaded Options: Audit and Trim Safely

WordPress autoloaded options are the rows in wp_options that get pulled into memory on every single request, front end and admin alike, whether the page needs them or not. When Site Health calls them out, the fix is almost never “delete them” — it is to leave the data alone and turn autoload off for the handful of rows that are carrying the weight.

The number that matters is the total serialized size of everything marked for autoload. WordPress 6.6 added a Site Health test that goes critical past 800,000 bytes with the label “Autoloaded options could affect performance”. That threshold is a prompt to look, not a cliff edge: a 900 KB total made of one abandoned plugin’s cache row is a five-minute fix, while 700 KB spread evenly across forty active plugins may be nothing you can do much about.

What WordPress autoloaded options actually are

Every row in wp_options has an autoload column. On boot, wp_load_alloptions() runs a single query that selects option_name and option_value for every row whose autoload value is in the set returned by wp_autoload_values_to_autoload(), then caches the whole lot under the cache key alloptions in the options group. After that, get_option() for any of those names is an array lookup rather than a query.

So one query is not the cost. The cost is everything else: transferring the payload from MySQL, unserializing it into PHP memory, and — if you have a persistent object cache — fetching and unserializing that same blob from the cache on every request. A 2 MB alloptions array is 2 MB of work your site does before it renders a single character, repeated for every uncached hit.

WordPress 6.6 reworked what the column can hold, and because there is no upgrade routine, an older site will have a mix of old and new values sitting side by side:

The auto-off value is where the dynamic part lives. Since 6.6, an option added or updated without an explicit true for autoload is not autoloaded once its value passes roughly 150,000 bytes, which the wp_max_autoloaded_option_size filter controls. That is a guard rail for new data only. It does nothing about the row a plugin wrote in 2021 with an explicit yes, which is usually the row you are hunting.

Measure before you change anything

Three ways to get the number, in descending order of how much I trust them.

WP-CLI, if you have shell access

# Total bytes of everything currently autoloaded
wp option list --autoload=on --format=total_bytes

# The twenty heaviest autoloaded rows, largest last
wp option list --autoload=on --fields=option_name,size_bytes \
  | sort -n -k 2 | tail -20

Note the sort pipe. wp option list --orderby accepts only option_id, option_name and option_value — there is no --orderby=size_bytes, and piping through sort -n is the approach WP-CLI’s own documentation uses. The --autoload=on filter matches autoloaded rows regardless of whether they say on, yes or auto, so you do not need to enumerate the values yourself.

SQL, if all you have is phpMyAdmin

-- Total autoloaded payload in kilobytes
SELECT ROUND( SUM( LENGTH( option_value ) ) / 1024, 1 ) AS autoload_kb
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto', 'auto-on' );

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

Swap wp_ for your own table prefix. Include all four values in that IN list — a query that checks only autoload = 'yes' will under-report on any site that has written options since 6.6, which is every site.

Site Health, if you have neither

Go to Tools → Site Health → Status. Under 800,000 bytes you get a passing result reading “Autoloaded options are acceptable”; over it, the test returns a critical status, the “Autoloaded options could affect performance” label, and the row count and total size. If you work on client sites, reading the rest of the Site Health panel properly is worth the ten minutes — this is one test among many that people scroll past.

What is usually taking up the space

Run the top-25 query and you will almost certainly recognise something from this list. The sizes are not the point — the pattern in the option name tells you what wrote it and therefore what is safe to do.

One row deserves a special mention because it panics people: core_updater.lock. It is tiny, it is temporary, and it has nothing to do with this. If you found it while poking around and your updates are stuck, that is the “another update is currently in progress” problem, not an autoload problem.

How to disable autoload without corrupting the value

Since WordPress 6.4 there has been a function for exactly this, and it changes the autoload column without reading, re-encoding or rewriting option_value:

<?php
// One option. Returns true if the autoload value changed.
wp_set_option_autoload( 'some_plugin_cached_feed', false );

// Several at once. Returns an array keyed by option name.
wp_set_option_autoload_values( array(
	'some_plugin_cached_feed'   => false,
	'some_plugin_license_check' => false,
	'theme_mods_twentytwenty'   => false,
) );

Pass booleans. The string values 'yes' and 'no' are still accepted but were deprecated in 6.7, so there is no reason to write new code with them.

From the shell, run that through wp eval rather than reaching for wp option update:

wp eval 'var_dump( wp_set_option_autoload( "some_plugin_cached_feed", false ) );'

If you truly only have database access, the UPDATE is one line — but the object cache will keep serving the old alloptions array until it is cleared, so the change will look like it did nothing:

UPDATE wp_options SET autoload = 'off'
WHERE option_name = 'some_plugin_cached_feed';

-- then, from the shell:
-- wp cache flush

Take a database export first. Not a backup you took — one you have restored somewhere and looked at. And if a careless edit here does take the site down with a database error, the database connection error walkthrough and enabling debugging to read the log will get you further than guessing.

Disable autoload or delete the row?

These are different operations with different risk profiles, and conflating them is how people break sites while “optimising” them. Disabling autoload is reversible, costs you one extra query on the requests that genuinely need the option, and cannot lose data. Deleting is permanent and can lose settings a plugin has no way to rebuild.

Clear expired transients while you are in there

Expired transients are not autoloaded, so they do not show up in your autoload total. They still bloat the table, slow down the queries that scan it, and get copied into every backup you take. Two commands:

# Safe: removes only transients whose timeout has passed
wp transient delete --expired

# On multisite, site transients are stored separately
wp transient delete --expired --network

wp transient delete --all also exists and I would not run it on a busy production site mid-morning. Every plugin that was relying on a cached value now rebuilds it on the next request that needs it, which can mean a burst of remote HTTP calls and database work arriving all at once. Run it when traffic is low, or stick to --expired.

A persistent object cache changes this picture: with Redis or Memcached in place, transients are stored in the cache rather than in wp_options, and there is nothing in the table to clean. If you are not sure which you have, Site Health tells you under Tools → Site Health → Info → Server.

When autoload bloat is not your real problem

Being honest about this saves you an afternoon. Shaving 300 KB off alloptions is a real improvement to time-to-first-byte on uncached requests, measurable in tens of milliseconds on a decent host. It is not going to rescue a site that is slow for a different reason.

A slow admin is usually several things at once. Autoload bloat is one of the four causes I check, alongside the Heartbeat API hammering admin-ajax.php, a jammed WP-Cron queue, and a single plugin running expensive queries on every admin screen. Diagnosing a slow WordPress admin dashboard works through all four in order, which is the right sequence if your complaint is “wp-admin is unusable” rather than “Site Health has a red box”.

It will not move your Core Web Vitals much. Autoload cost is server-side work that lands in TTFB. If your problem is interaction latency, the bottleneck is JavaScript on the main thread, and diagnosing a failing INP score is where to spend the time instead. If page caching is serving most of your traffic, the front end barely pays the autoload cost at all — but every logged-in request and every uncacheable page still does.

There is one way this gets genuinely bad. Memcached’s default maximum item size is 1 MB, set by -I / --max-item-size. An alloptions array larger than that cannot be stored, so the set silently fails, every request misses the cache, and your “optimised” site queries and unserializes the whole thing from MySQL every time — while the dashboard cheerfully reports a persistent object cache in use. Crossing 1 MB of autoloaded options on a Memcached host is not a slow degradation, it is a step change. Redis does not have the same low ceiling, but the unserialization cost is still real.

If one plugin owns most of the total, the plugin is the decision. I have seen a single slider plugin account for 1.4 MB of autoloaded options. You can disable autoload on its rows every quarter, or you can replace it. Work out which plugin is responsible first — the step-by-step plugin conflict process is the same deactivate-and-measure discipline applied to a different symptom.

A repeatable 15-minute audit

1. Export the database, and confirm the export is restorable.
2. Record the starting number: wp option list --autoload=on --format=total_bytes.
3. List the top 20 rows and write down which plugin owns each one. Anything you cannot attribute, leave alone for now.
4. Delete only rows belonging to plugins that are no longer installed.
5. For everything else over about 50 KB that is clearly admin-only, call wp_set_option_autoload_values() once with the whole batch.
6. wp transient delete --expired, then wp cache flush.
7. Re-run the total, then click through the front end, the editor, and the settings screen of every plugin you touched. Autoload changes break things silently, not loudly.
8. Note the date and the new figure somewhere you will find it. This grows back.

Step 7 is the one people skip and the only one that catches a mistake. A plugin whose licence row you set to off may read that option in a context where an extra query is fine, or it may have been written on the assumption that the value is always already in memory. You find out by looking, not by reasoning about it.

Frequently asked questions

Sources

• Options API: Disabling autoload for large options on make.wordpress.org — the autoload column values, the 150,000-byte default and the wp_max_autoloaded_option_size filter
• WP_Site_Health::get_test_autoloaded_options() — the 800,000-byte threshold, the critical status and label, and the three filters
• wp_load_alloptions() — the alloptions cache key, the options group, and the load-everything fallback
• wp_set_option_autoload() and wp_set_option_autoload_values() — added in 6.4.0, string values deprecated in 6.7.0
• set_transient() — source for non-expiring transients being autoloaded and expiring ones not
• wp option list, wp option update and wp transient delete in the WP-CLI command reference
• memcached(1) manual page — the 1 MB default for -I / --max-item-size