A slow WordPress admin, sometimes with 503 errors, can trace back to autoloaded options: settings in the wp_options table that WordPress loads on every request. Since WordPress 6.6, Site Health flags a critical issue when they add up to more than 800 KB. Back up the database, find the largest autoloaded options and the plugin that owns each one, then turn autoload off for big options that aren’t needed on every page instead of deleting them.
What are autoloaded options?
WordPress, its theme and its plugins store their settings as options, which WordPress keeps in the wp_options table of your database. Each row has a name, a value and an autoload flag. According to the WordPress core team’s WordPress 6.6 developer note, WordPress loads all autoloaded options with a single query on each page request, to save making many small queries later.
That works well while the autoloaded data stays small. The trouble is the old default: a plugin that didn’t say otherwise got its options autoloaded, and the same note says this led to many options being loaded on every page unnecessarily. A plugin that keeps a cache, a debug log or a long list in one option can add a large block of data that WordPress reads on every request, including every screen in wp-admin, even if only one settings page ever uses it.
This is a server-side problem, so it shows up as slow admin screens and slow first responses rather than heavy images. If visitors see slow pages on their phones, start with why is my website slow, which covers images, scripts and Core Web Vitals. If the admin crawls and you would rather not touch the database yourself, our WordPress speed and error fixes start with the same checks, made on a backup copy.
How do I check the size of my autoloaded options?
There are three ways, from easiest to most detailed. All three only read data; none of them change anything.
1. Site Health (WordPress 6.6 and later)
Go to Tools > Site Health and open the Status tab. WordPress 6.6 added a test that adds up the size of all autoloaded options. If the total is more than 800 KB, it shows a critical issue, “Autoloaded options could affect performance”, with the number of autoloaded options and their total size. WordPress’s optimization guide puts it in plain words: generally, try to keep your site’s autoloaded options under 800 KB.
Site Health gives you the total, not the list. The developer note points to the Performance Lab plugin from the WordPress Performance Team, which extends the same Site Health check with a table of the largest autoloaded options and a way to turn autoload off for each one.
2. WP-CLI
If your host gives you SSH access with WP-CLI, these commands list autoloaded options and their size without opening the database directly:
- wp option list --autoload=on --format=total_bytes (the total size of autoloaded options)
- wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail -20 (the 20 largest, biggest last)
One catch: in WP-CLI’s current source code, --autoload=on matches only rows stored as on or yes. Options stored as auto or auto-on, which WordPress also autoloads (see below), are left out, so treat the WP-CLI total as a minimum and compare it with Site Health.
3. A SQL query
In phpMyAdmin or another database tool, these two read-only queries give the total and the 20 largest autoloaded options. Replace wp_ with your own table prefix, which is set by the $table_prefix line in wp-config.php and is often something other than wp_.
- SELECT SUM(LENGTH(option_value)) AS autoload_bytes FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
- 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;
The list of values matters. Since WordPress 6.6 the autoload column can hold yes, no, on, off, auto, auto-on or auto-off, and WordPress autoloads yes, on, auto-on and auto by default. An older query that only looks for yes will miss options saved since then. MySQL’s LENGTH() counts bytes, so the result compares directly with the 800 KB guideline.
What usually bloats autoloaded options?
Look at the names of the largest rows. Most start with a prefix that points to the plugin or theme that wrote them. The usual suspects:
| What you find | Why it happens | What to do |
|---|---|---|
| Options from plugins you removed | WordPress’s plugin handbook tells developers to delete their options on uninstall, which means deactivating and then deleting the plugin in the admin. Not every plugin does, and a plugin folder removed over FTP never runs that step. | Confirm the plugin is gone for good, back up, then remove its options |
| Large transients (names starting with _transient_) | Transients are temporary cached data that WordPress stores in wp_options when there is no persistent object cache | Delete expired transients; report a large autoloaded one to the plugin’s developer |
| Logs, debug data or long lists saved as one option | Some plugins keep logs or stats in a single option that grows over time | Turn the logging off in the plugin, then turn autoload off for that option |
| Page builder or theme settings | Large but often needed on every front-end page | Usually leave autoloaded; ask the developer before changing |
Community threads on the WordPress.org support forums show these patterns. In one thread, a site owner found an anti-spam plugin’s debug option of 125 kB autoloaded on every request, and the plugin’s developer later released a version without that code. In another, a transient named _transient_dirsize_cache was the largest autoloaded option at about 1.7 MB. These are user reports, not official guidance, but they show why the owner of each large option is worth finding.
How do I fix autoloaded options safely?
- Back up the database first. Export the whole database with your host’s backup tool, phpMyAdmin or wp db export, and keep the file off the server. Ideally, test on a staging copy.
- Identify the owner of each large option. Match the name prefix to an installed plugin or theme. If you can’t tell, search the plugin’s files or ask its developer; don’t guess.
- Turn autoload off instead of deleting. For an option that belongs to an active plugin but isn’t needed on every page, switching autoload off keeps the data, and WordPress loads it only when the plugin asks for it. With WP-CLI: wp option set-autoload option_name off. Performance Lab offers the same from the Site Health screen.
- Remove leftovers only from plugins you have deleted for good. If you might reinstall the plugin, keep its settings. Delete rows one at a time and test the site after each.
- Clear out expired transients. wp transient delete --expired removes them. WordPress’s Transients API documentation tells developers that a transient can disappear at any time and that their code should regenerate the data when it is missing.
- Check again. Re-run Site Health or the total query, then click through the admin, the front end, forms and any checkout.
WordPress 6.6 also stops the problem growing. When an option is added or updated without the plugin explicitly asking for autoload, WordPress no longer autoloads it if the value is larger than 150,000 bytes. Two limits apply: options saved before 6.6 keep their old yes or no value, because there is no upgrade routine, and a plugin can still force autoload by passing true. So an older site can still carry large autoloaded options from years ago.
If the same plugin keeps writing a huge option back, the fix belongs in the plugin: update it, report it to its developer, or replace it. Turning autoload off by hand can be undone by the plugin’s next update.
What else causes a slow admin and 503 errors?
A 503 Service Unavailable response means the server isn’t ready to handle the request; common causes are maintenance or an overloaded server. Autoloaded options are one way a WordPress site uses more memory and time per request, but they are not the only one. Check these as well:
- PHP workers. Your server runs a limited number of PHP processes at once; in PHP-FPM, the pm.max_children setting sets the maximum. When every one is busy with slow requests, new requests have to wait, and an overloaded server may answer with a 503. Ask your host how many your plan allows and whether you are hitting the limit.
- The Heartbeat API. Each open admin tab polls the server every 15 to 120 seconds through admin-ajax, according to WordPress’s Heartbeat API documentation. Several people with several tabs open each add requests that compete for the same PHP workers.
- WP-Cron. WordPress runs scheduled tasks during page loads. WordPress’s plugin handbook explains how to run them from the server’s own scheduler instead and turn off the page-load check with define( 'DISABLE_WP_CRON', true ); in wp-config.php. Set up the server task first, or scheduled posts and updates stop running.
- Memory limits. Autoloaded data is loaded into PHP memory on every request. If you also see “Allowed memory size exhausted” errors, see our guide to the WordPress memory exhausted error.
- Update maintenance. WordPress’s common errors page notes that a .maintenance file left behind after an update shows “Briefly unavailable for scheduled maintenance” until it is removed.
If the site shows “There has been a critical error on this website” instead of a 503, the cause is different; see our WordPress critical error guide.
When should I get help?
- You can’t tell which plugin owns the largest options, or the owner is a plugin the site depends on, such as the shop or booking system.
- Autoloaded options are under 800 KB and the admin is still slow, or 503 errors continue.
- You don’t have database access or a recent backup you have tested.
- The site takes orders or bookings and you can’t risk downtime while testing.
Admin still slow? Request a free website audit for a reviewed summary of what to fix first. If 503 errors are hurting the site now, describe what is broken and we’ll reply with the likely cause and the next step.
Frequently asked questions
What is a safe size for autoloaded options?
WordPress doesn’t define a safe size, but it gives a guideline: its optimization guide says to generally keep autoloaded options under 800 KB, and since WordPress 6.6 Site Health reports a critical issue when the total is more than 800 KB. Under that, autoloaded options are unlikely to be your main problem. Since 6.6, WordPress also stops autoloading a single option larger than 150,000 bytes when it is saved, unless the plugin asks for it.
Can I delete options from wp_options?
Only with care, and after a database backup. Deleting a row that an active plugin, the theme or WordPress itself still uses can reset settings or break features. Delete options only from plugins you have removed for good, one at a time, testing after each. For a large option that is still in use, turn autoload off instead: the data stays, and WordPress loads it only when it is needed.
Will an object cache fix it?
It helps but doesn’t remove the cause. WordPress’s optimization guide says a persistent object cache, such as Redis or Memcached through your host, saves trips to the database, and that options, autoloaded or not, load faster with one. The data is still loaded on every request, so very large options still use memory. Reduce oversized autoloaded options first, then add an object cache if your host offers one.
Why did the Site Health warning appear after an update?
The test was added in WordPress 6.6, so sites updating to 6.6 or later saw it for the first time even if nothing else had changed. A plugin update can also add large options. List the largest autoloaded options with Performance Lab, WP-CLI or the SQL query above, find which plugin owns the biggest ones, and check that plugin’s changelog or support forum before changing anything.
Sources
- Make WordPress Core: Options API, disabling autoload for large options (WordPress 6.6 dev note)
- WordPress Advanced Administration Handbook: Optimization (autoloaded options, object cache)
- WP-CLI Commands: wp option list
- WP-CLI on GitHub: Option_Command.php (how --autoload=on is matched)
- WordPress Plugin Handbook: Heartbeat API
- WordPress.org support forum: Turn off autoload for cleantalk_debug in wp_options (community thread)
- WordPress.org support forum: Autoloaded Options _transient_dirsize_cache (community thread)