Site Health has started showing a warning you have not seen before. It says your site’s autoloaded options could be affecting performance, gives a size, and suggests you look into it. You have not changed anything recently. The site has simply been running for a few years, with plugins installed, tested, kept or deleted along the way.
Autoloaded options in WordPress are one of those things nobody thinks about until a warning appears. They are also one of the few places where years of small leftovers quietly add a cost to every uncached page on the site. Here you will find what autoload means, how to see what is in there, what typically causes large autoloaded data, and how to clean it up without breaking anything.
What “autoload” means
WordPress stores settings in a database table called wp_options (the prefix may differ on your site). Your site title, the active theme, widget settings, plugin settings, licence keys and many other small pieces of data each live in a row there.
Each row has an autoload flag. When it is switched on, that option is loaded in a single batch at the start of every request WordPress handles, whether the page needs it or not. The idea is sensible: settings that nearly every page uses are fetched in one go instead of one at a time.
The trouble is that the flag is set by whoever creates the option. Plugin developers often leave it on by default, including for data that is large or rarely used. And when a plugin is deleted, its options usually stay behind, still flagged to load on every request.
Older sites store the flag as yes or no. Recent WordPress versions write newer values instead: on and off when a plugin chose explicitly, and auto, auto-on or auto-off when WordPress decided. A site that has been updated over the years usually has a mix of old and new values in the same table, and the old ones still work.
Why autoloaded options in WordPress can slow a site
Every uncached request pays for it: the visitor’s page if it is not cached, every admin screen, every background AJAX call, every REST API request and every scheduled task. WordPress reads the whole batch from the database, then unpacks it into memory.
When that batch is small, the cost is too small to notice. When it has grown large, several things happen:
- The database query that fetches it takes longer.
- PHP spends time unpacking data that the page never uses.
- Each request needs more memory, which matters on shared hosting where memory is capped across the account.
- If you use a persistent object cache, the same oversized batch is stored and fetched from the cache instead, which helps but still moves a lot of data around on every request.
Cached pages served without loading WordPress are not affected, which is why this problem often shows up as a slow admin, slow checkout or slow logged-in experience while the public site looks fine.
What usually fills it up
- Leftovers from removed plugins. Settings, logs and cached data from plugins deleted years ago, still loaded on every request.
- Plugins storing big data as a single option. Some save logs, statistics, lists of URLs or entire configuration exports in one row, with autoload on.
- Transients that never expire. On sites without a persistent object cache, transients live in the options table. Ones saved with no expiry time are autoloaded, and some plugins create them freely.
- Page builder and theme settings. Global styles, font lists and template data can be large, though these are often genuinely needed.
- A bloated cron schedule. WordPress’s list of scheduled tasks is itself an autoloaded option. A plugin that schedules thousands of one-off events makes it heavy.
How to see what is being autoloaded
Start with Site Health
Tools, then Site Health, flags the problem when the total autoloaded size passes a level WordPress considers a concern. It tells you the overall size, but not which options are responsible. Our post on reading the Site Health screen covers the other checks on that page.
List the largest rows
To find the culprits, you need to look at the table itself, through phpMyAdmin in your hosting panel or a database plugin. A query along these lines lists the twenty largest autoloaded options:
SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') ORDER BY size DESC LIMIT 20;
The list of values covers both old and new sites: yes from older versions, plus on, auto and auto-on, which recent versions treat as loading on every request. Rows marked no, off or auto-off are left out, because they are only fetched when something asks for them. On a site that has never run a recent version, the newer values simply match nothing, so the same query works either way. Change wp_options to match your table prefix if it is different. This only reads data; it changes nothing.
Identify each one
Go down the list and work out who owns each large option. The name usually helps: most plugins prefix their options with a short version of their name. Write down for each one:
- The option name and its size.
- Which plugin or theme it seems to belong to.
- Whether that plugin is still installed and active.
If a name tells you nothing, searching for it together with “WordPress” usually finds the plugin quickly.
Cleaning up without breaking things
Work carefully here. The options table holds settings that your site depends on, and some data cannot be recreated if it is deleted.
- Take a fresh database backup and confirm you know how to restore it. Do the work on a staging copy first if you have one.
- Deal with plugins you actually removed. If an option clearly belongs to a plugin that is no longer installed, it can usually be deleted. Check first that it is not shared with a sister plugin you still use.
- For active plugins, change the flag rather than delete. Setting a large option’s autoload value to
off(ornoon an older WordPress version, which recent versions also still understand) means it is fetched only when the plugin asks for it. The plugin still works; it just stops burdening every other request. This step is easy to reverse. - Look at the plugin’s own settings. Some plugins have an option to stop storing logs, to clear old data or to limit history. That is better than editing their rows by hand.
- Clear expired and orphaned transients. Many cleanup plugins do this safely.
- Test after each change. Load the homepage, a contact form, the admin, and on a store a product, the cart and checkout. Check that settings pages for the plugins you touched still show their values.
Then measure again. Run the same query, compare the total, and see whether Site Health’s warning has cleared. Note uncached response times on the admin and a logged-in page before and after, so you know whether it made a difference you can feel.
A worked example of the decision
Say your list shows three large rows. The first belongs to a slider plugin you replaced two years ago and deleted; it can go, after the backup. The second belongs to your active SEO plugin and holds a big block of redirect data; you leave it in place but ask whether the plugin offers a setting to store redirects differently, and if not, switch its autoload flag off on staging and test that redirects still work. The third is a core WordPress option; you leave it alone, whatever its size. Each row gets its own decision, and none of them is “delete everything over a certain size”.
What not to do
- Do not bulk-delete everything that looks unfamiliar. Core WordPress options, theme settings and active plugin settings all live here. Removing one can reset a feature or break the site.
- Do not switch autoload off for core settings. Options such as the site address and active plugins list are meant to load every time.
- Do not treat it as a one-off. The plugin that created a huge option will create it again. Find the setting that stops it, or replace the plugin.
- Do not expect miracles on a cached site. If most visitors get cached pages, this cleanup mostly helps the admin, logged-in users and stores.
Keeping it small
Autoloaded data creeps back for the same reasons it grew. A few habits keep it in check:
- When you remove a plugin, look for a “delete data on uninstall” setting first, and use it if you are sure you will not return to that plugin.
- Check Site Health monthly, and run the size query every few months on a busy site.
- Be wary of plugins that log every visit, every email or every search into the database.
- If your host supports it, a persistent object cache softens the cost; our post on Redis object cache for WordPress explains when it helps.
For the rest of the database, revisions, spam and orphaned tables, see our guide to WordPress database cleanup. That work helps backups and the admin; this autoload check is the part that touches every request. Both sit under our section on the server side of website speed, part of the wider website loading speed guide.
Frequently asked questions
How big is too big for autoloaded options?
There is no single safe number for every site, and the effect depends on the server. The practical signs are Site Health raising its warning, a handful of individual options that are far larger than the rest, and uncached pages or the admin being slower than they should be. Fix the largest rows first and measure the difference.
Will deleting a plugin remove its autoloaded options?
Often not. Many plugins leave their settings behind when deleted, on purpose, so that reinstalling restores your configuration. Some offer a setting to remove all data on uninstall. If a plugin does not, its options stay in the table until someone removes them by hand.
Can a cleanup plugin fix autoloaded options for me?
Some database cleanup plugins list autoloaded options and let you change the flag or delete rows, which saves writing queries. They still cannot tell you for sure whether an option is safe to remove. Use them to find and sort the data, and make the final decision yourself after checking who owns each option.
Why did the autoload warning appear when nothing changed?
Two common reasons. The check itself is a fairly recent addition to Site Health, so a site that has carried the same data for years may only now be told about it after a WordPress update. Or a plugin has recently started saving a large option. The size query shows which rows are biggest, which usually settles it.
If you would rather not edit the options table yourself, Our website speed optimisation service covers WordPress database cleanup and optimisation as part of a wider audit, and nothing in the database is touched until you have approved the fix list.
Next in this series: Slow DNS Lookup: Where It Hurts and What to Change
