WordPress
Autoload Bloat

Audit Your Autoloaded Data: Two Queries

Paste these into phpMyAdmin, Adminer, or wp db query - the first gives your total autoload size in KB, the second lists the 25 options actually causing it. Adjust the wp_ prefix if yours differs.

-- Total autoloaded data (KB) + row count
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb,
       COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

-- Top 25 offenders, biggest first
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;

WordPress Autoloader vs Autoloaded Data

"Autoloader" means two unrelated things in WordPress, and searching for it returns both. Worth thirty seconds to check which one you have.

If you arrived here after a host flagged "autoloaded data", or after seeing alloptions in a profiler, you want the second one. If you are debugging a Class not found fatal, you want the first, and this page will not help - that is a Composer or PSR-4 problem.

The phrase "plugin autoloader" is ambiguous in the same way. A plugin ships a Composer autoloader for its own classes, and it also writes autoloaded options. Only the second shows up in the query below.

What Is Autoloaded Data?

WordPress has a single query that runs on every page load, before any theme or plugin code executes:

SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes'

This loads all "autoloaded" options into memory at once. WordPress core needs about 100KB of this data. The problem is that plugins abuse it.

Unlike slow queries that spike your TTFB intermittently, autoload bloat is a constant tax. It adds latency to every single request—cached or not, frontend or admin, AJAX or page load.

WP Engine "Autoloaded Data" Warning: What To Do

WP Engine flags autoloaded data once it passes 800 KB and calls anything below that within normal range. It is one of the few hosts that surfaces this as a dashboard warning, which is why most people meet the problem through them. The physics are host-agnostic - every request pulls the whole set into PHP whoever you are with.

The warning tells you a number and nothing else. Here is what to do with it.

1. Measure it yourself first. Run the audit query at the top of this page. Host dashboards sample on a schedule, so the number you see can be hours old, and some panels still test autoload = 'yes', which undercounts on WordPress 6.6+ because core now also writes 'on', 'auto' and 'auto-on'. A panel saying "within normal range" is not proof.
2. Find the offenders, not the total. The total is a symptom. List the top 25 rows by LENGTH(option_value) and you will usually find three or four rows carrying most of the weight.
3. Check each one against the do-not-touch list further down this page before changing anything. Some large autoloaded options are supposed to be large.
4. Flip autoload off, do not delete. wp option set-autoload OPTION_NAME off leaves the data intact and reversible. Deleting rows is how you break a plugin's settings.
5. Re-measure and let the panel catch up. The warning clears on WP Engine's next check, not instantly.

One caveat specific to managed hosts on memcached: above roughly 1 MB the autoload blob can exceed the per-key limit, so it silently fails to cache and every request goes back to the database. That is worse than the warning suggests, and it shows up as random 502s in wp-admin rather than as a slow page.

Getting under 800 KB by hand is a couple of hours of careful work. WP Multitool's Autoloader Optimizer does the same audit, categorises every row, and flips the safe ones with a one-click restore behind it.

What Causes WordPress Autoload Bloat

1. Deactivated Plugin Leftovers

Most plugins don't clean up after themselves. They add options on activation and leave them forever—even after deactivation and deletion. Find them:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Look for option names from plugins you no longer use. These are safe to set to autoload='no' or delete entirely.

2. Serialized Arrays That Grow

Some plugins store growing data in a single option: logs, analytics snapshots, cron schedules. A single option_value can be 500KB+ of serialized PHP.

3. Expired Transients

Transients are temporary cached values stored in wp_options. Without an external object cache, expired transients accumulate. WordPress only cleans them lazily—when they're next accessed. These stale transients can also show up as slow queries when the table grows large enough.

SELECT COUNT(*) FROM wp_options
WHERE option_name LIKE '_transient_%'
AND autoload = 'yes';

4. Misconfigured Plugins

Plugins that store per-user settings, large JSON configs, or cached API responses in autoloaded options. The data might be needed, but it doesn't need to load on every request.

What NOT to Turn Off

Flipping autoload is reversible. Deleting rows is not. But some options must stay autoloaded while their owner is active, or WordPress and your plugins break early in the bootstrap - and it won't error, it will just quietly degrade. Use this as a check before any bulk change.

The rule: if the plugin is active and the option is configuration it reads on every request, leave autoload on. If the plugin is gone, or the value is a cache, log, or queue blob, disable autoload first - and only delete once you've confirmed nothing still reads the row.

Common Autoload Offenders: Is It Safe to Disable?

Twenty prefixes I see over and over, and what I do with each. "Caution" means the answer depends on whether the plugin is still active - check that first.

How to Fix Autoload Bloat in WordPress

Disable Autoload for Specific Options

UPDATE wp_options SET autoload = 'no'
WHERE option_name = 'old_plugin_settings';

Clean Expired Transients

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Delete Orphaned Plugin Data

-- Only after confirming the plugin is gone:
DELETE FROM wp_options
WHERE option_name LIKE 'removed_plugin_%';

The problem with manual fixes: they don't stay fixed. Plugins keep adding data. Transients re-accumulate. New plugins bring new autoloaded options. You'd need to audit monthly to keep it under control.