WordPress stores settings in the wp_options table, and the ones marked as autoload are loaded on every single page view, whether the page uses them or not. As long as they’re small, that’s a benefit. When plugins store large amounts of data there, or leave settings behind when they’re uninstalled, every page gets a little heavier, including the pages in a store that can’t be cached.
This guide shows how to see how much is autoloaded, how to find the large options, and what you can safely do about them.
What autoload means
Each row in wp_options has a column, autoload, that says whether the option should be loaded together with all the others when WordPress starts. That saves a database query per option for the ones used everywhere, such as the site address and the active plugins. The downside is that everything marked is loaded every time, even when it’s only used on one admin page.
Since WordPress 6.6, the column can hold more values than the old yes and no: on and off when a plugin has chosen, and auto when WordPress decides. At the same time, WordPress stopped autoloading new options over 150 KB unless a plugin asks for it. That’s in WordPress’s own write-up of the change. Options that were already stored keep their setting.
How much does your store autoload?
The quickest answer is under Tools → Site Health. Since WordPress 6.6, it shows a critical issue saying autoloaded options could affect performance when they add up to more than 800 KB. If that warning is there, it’s worth a closer look. If it isn’t, autoload is rarely the cause of a slow store.
If you have database access, for example through phpMyAdmin at your hosting provider, you can see the exact number and the largest options. The table prefix isn’t always wp_, so adjust the name to yours:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;An option’s name often starts with the plugin’s name or abbreviation, which tells you who it belongs to. If you’re unsure, search for the name.
Where the large options come from
- Plugins that are gone: Many plugins leave their options behind when they’re uninstalled. If the store has changed plugins a few times, there are often options nothing uses.
- Plugins that use options as storage: Logs, statistics, product lists or API responses saved as one large option with autoload on.
- Page builders and themes: Large amounts of CSS, layout or font data stored in options.
- Temporary data: Without an object cache, WordPress and plugins store temporary data, transients, in
wp_options. Those with an expiration usually aren’t autoloaded, but those without one can be.
How to fix it safely
Back up the database before you change anything, and ideally try it on a copy of the store first. Then go through the largest options one at a time:
- If it belongs to a plugin that’s no longer installed, it can be deleted.
- If it belongs to an active plugin and is only used in one place, such as a log or a statistic in the admin, autoload can be turned off so it’s only loaded when needed. Set
autoloadtoofffor that option. The plugin still works; it just loads the option itself. - If it belongs to an active plugin and is used everywhere, leave it, and raise it with the plugin’s developer if it’s very large.
Never delete options from plugins you still use, and don’t touch WordPress’s own options, such as siteurl, home, active_plugins and cron. If you can’t tell what an option is used for, turn autoload off instead of deleting it. That can always be turned back on.
Does an object cache help?
Partly. With an object cache such as Redis, autoloaded options are fetched from memory instead of the database, and transients move out of wp_options entirely. But the options still have to be fetched and unpacked on every page view, so large amounts still cost time and memory. An object cache isn’t a reason to leave them.
Autoload is one of several things that make the database heavier over time. The others are in the database section of the troubleshooting guide and in our guide to WordPress database performance. If it’s the PHP code that uses the time, see PHP optimization in WordPress.
Frequently asked questions
How much autoload is too much?
WordPress’s own check warns at 800 KB in total. That’s not a limit where the store stops, but a point where it’s worth a look. A single large option often matters more than the total.
Can a cleanup plugin handle it?
It can show the large options and turn off autoload. But it can’t know whether an option is still in use, so the decision is yours. Don’t delete blindly.
Want help?
The hard part of autoload is knowing what can safely go. If you’d like us to go through your database, read about optimizing your WooCommerce store. We take a free look at your store first and tell you what it will take.