Every time WordPress loads, whether for a page view, an admin screen, an AJAX request or a cron job, one of the first things it does is run a single database query to load all options marked for autoloading. These are settings that WordPress, the theme and plugins expect to need on most requests, so loading them all at once is efficient. On a fresh installation, the total is small, a few hundred kilobytes at most. Cleaning up autoloaded options is one of the quickest ways to make every request lighter.
On a site that’s been running for years, it can be a very different story. Plugins that were installed, tried and deleted often leave their settings behind. Some plugins store large data, like cached API responses or logs, in autoloaded options. Over time, autoloaded options can grow to several megabytes, and every one of those bytes is loaded into memory on every single request, including requests that never use them. Cleaning them up is one of the more satisfying performance fixes, because it helps every page, every admin screen and every background task at once.
How autoloading works
The wp_options table has a column called autoload. Historically, its values were “yes” or “no”. Since WordPress 6.6, core uses more descriptive values, such as on, off, auto, auto-on and auto-off, which let WordPress decide automatically for options where the plugin didn’t specify a preference, and avoid autoloading options that are too large.
When WordPress starts, wp_load_alloptions() fetches every option with an autoload value that means “load”, and keeps them in memory. If a persistent object cache like Redis is active, the whole set is stored as a single cache entry, which means a very large autoload set also creates a very large cache object that must be fetched and unserialised on every request.
Measuring the total
WordPress Site Health now includes a check for autoloaded options. Go to Tools, Site Health and look for a warning about autoloaded options. It reports the total size and warns when it’s above a threshold.
For more detail, use WP-CLI. This query shows the total size of autoloaded data:
As a rough guide:
- Under 500 KB: healthy
- 500 KB to 1 MB: worth reviewing
- Over 1 MB: likely affecting performance
- Several MB: definitely worth cleaning up
Finding the heaviest options
List the largest autoloaded options:
The output usually tells a clear story. You’ll see option names with plugin prefixes, and a handful of options often make up most of the total. Typical culprits:
- Leftovers from deleted plugins: option names belonging to plugins no longer installed
- Cached data: options storing API responses, feeds, statistics or rendered HTML
- Logs: some plugins store logs or event history in a single option that grows forever
- Builder and theme data: page builder global settings, CSS caches and font lists
- Transients without expiry: transients that were stored without an expiration are autoloaded
Also count how many options are autoloaded:
Thousands of small autoloaded options can also add up, though size usually matters more than count.
Deciding what to do with each option
For each large option, ask three questions.
Does it belong to an active plugin or theme?
Search the codebase for the option name:
If nothing references it, it’s probably a leftover. Check the name against plugins you know were previously installed.
Is it needed on every request?
Some options from active plugins are needed only in the admin or only on specific pages. Those can be set to not autoload. The plugin will still load them when needed, with a separate query, which is far cheaper than loading them on every request.
Is it cache data that could live elsewhere?
Large cached data belongs in a transient with an expiry, in the object cache, or in a custom table, not in an autoloaded option. If an active plugin stores large data this way, report it to the developer and consider switching autoload off for that option.
Making changes safely
Before changing anything, take a database backup. Then work through the list carefully.
Turning off autoload
For options that should stay but don’t need autoloading, WordPress 6.4 and later include functions to change the autoload value. With WP-CLI:
On older WP-CLI versions without that command, you can update the column directly:
Test the site afterwards. The plugin should continue to work, just loading the option on demand.
Deleting leftovers
For options from plugins that are definitely gone:
Delete only what you’re confident about. If an option name is ambiguous, set it to not autoload first, wait a week and delete it later if nothing breaks.
Clearing expired transients
Transients stored in the options table without a persistent object cache can accumulate. Delete expired ones:
On sites without an object cache, you can also delete all transients, which plugins will regenerate as needed:
Expect a few slower requests while caches rebuild.
What not to delete
Some options look large but are essential:
- active_plugins, template, stylesheet and siteurl and other core options
- cron, which stores scheduled tasks and can be sizeable on busy sites
- rewrite_rules, which can be large on sites with many custom post types
- widget and sidebar settings
- User roles, stored as wp_user_roles
If the cron option is very large, that’s a sign of a different problem, usually a plugin scheduling too many events, which is worth investigating separately.
Preventing the problem from returning
Once cleaned up, keep it healthy:
- Remove plugins properly. Some plugins offer an option to delete their data on uninstall. Use it when you’re sure you won’t reinstall.
- Use a persistent object cache such as Redis, so transients don’t live in the options table.
- Check Site Health periodically, which flags autoload growth.
- Review the largest options every few months, or after adding major plugins.
- For developers, pass false as the autoload argument to add_option and update_option for anything that isn’t needed on most requests, and never store large or growing data in an option.
Measuring the improvement
After cleaning up, compare:
- Autoloaded data size before and after
- Memory usage per request, visible in Query Monitor
- Time to first byte for uncached requests, such as admin pages
- The size of the alloptions cache entry if you use Redis
On sites where autoloaded options had grown to several megabytes, I’ve regularly seen admin pages and uncached requests become noticeably faster, and PHP memory usage per request fall significantly. It’s a fix that benefits every request on the site at once, which makes cleaning up autoloaded options one of the best returns on half an hour of database work.
A real example
On one membership site I worked on, the autoloaded total was a little over 9 MB. Three options accounted for most of it. The largest was a cached copy of an external course catalogue, stored by an integration plugin and refreshed daily, around 4 MB on its own. The second was the log of a removed security plugin, still sitting in the options table more than a year after the plugin was deleted. The third was a page builder’s cached font list.
We moved the catalogue cache to a transient with an expiry and switched its autoload off, deleted the old security log and left the font list alone because the builder needed it. The autoloaded total dropped to under 700 KB. Memory usage per request fell by roughly a third, and uncached admin pages became noticeably faster. The whole job took less than an hour, most of it spent confirming which plugin owned which option.
Multisite considerations
On a multisite network, each site has its own options table, and the network has a separate sitemeta table for network-wide settings. Autoload bloat can exist in every subsite’s table independently. If you manage a large network, run the size query for each site’s table, because one subsite with a misbehaving plugin can be much heavier than the rest. WP-CLI’s –url parameter lets you run commands against each site in turn.
Working with your host
On managed hosting without shell access, you can still investigate. Site Health shows the total, and database tools like phpMyAdmin let you run the same queries shown above. Some managed hosts also include autoload reports in their dashboards. If you’re unsure about deleting something, export the option’s value first so you can restore it later if needed.
Frequently asked questions
Can I delete everything with autoload set to yes?
No. Many autoloaded options are essential. Only change or delete options you’ve identified as unnecessary.
Will a caching plugin fix this?
Page caching reduces how often WordPress loads at all, which hides the problem for cached pages. Uncached requests, admin pages and background tasks still pay the cost.
Is there a plugin to do this?
Some database cleanup plugins list autoloaded options and let you change or delete them. They’re convenient, but the same caution applies: understand each option before changing it.
Why did WordPress change the autoload values?
The new values let WordPress make better automatic decisions, such as not autoloading very large options by default, which reduces this problem on newer sites.
