Why your WordPress admin got slow, and why it is probably autoload

A slow WordPress admin is one of the more frustrating performance problems, because the usual advice does not apply. Caching plugins do not help — wp-admin is deliberately uncached. A CDN does not help. Upgrading your hosting plan often does not help either, which is how people end up paying more for the same problem.

The cause, more often than anything else, is autoloaded options. This post explains what that means, how to measure it, and how to fix it without breaking your site.

What autoload actually does

Every WordPress page load starts by querying the wp_options table:

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

Everything that returns is loaded into memory and kept for the duration of the request. That is the point — options marked autoload are things WordPress expects to need on essentially every request, so fetching them in one query beats fetching them individually.

The mechanism is sound. The problem is that it is opt-in by default and nobody cleans up.

When a plugin stores a setting with add_option(), autoload defaults to yes unless the developer explicitly says otherwise. Most do not. So every plugin you have ever installed has probably added its settings to the set of data loaded on every request — and if you deactivated the plugin without deleting its data, those options are still being loaded, forever, for a plugin that no longer runs.

Add a few years of that, plus expired transients that never got cleaned up, and a site can reach several megabytes of data being deserialised on every single request.

The numbers that matter

Rough guidance on total autoloaded size:

Entry count matters less than total size, but more than a thousand autoloaded entries usually indicates the same underlying neglect.

You can measure it directly:

SELECT
  COUNT(*) AS entries,
  ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS kb
FROM wp_options
WHERE autoload = 'yes';

And find the specific offenders:

SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

That second query is the useful one. Autoload bloat is rarely evenly distributed — it is usually three or four options doing almost all of the damage.

What you will find at the top of that list

In my experience the same categories come up repeatedly.

Expired transients. Transients are meant to be temporary cached values, and they are supposed to be cleaned up when they expire. In practice, expired transients frequently linger in wp_options indefinitely, particularly on sites without a persistent object cache. On a neglected site these can be the majority of the table. They are safe to delete: a transient is by definition regenerable.

Orphaned plugin settings. Options from plugins you removed years ago. Deactivating a plugin does not delete its data, and uninstalling often does not either. These are safe to delete once you have confirmed the plugin is genuinely gone, but confirm first — some plugins use a name prefix that does not match their slug.

Genuinely large single options. Some plugins store a big serialized blob — a licence cache, an import log, a settings array with hundreds of keys. These are usually still in use, so deleting them will break something. The right fix is to switch them off autoload rather than remove them.

Cron. The cron option holds every scheduled event. On a site with a large cron backlog this grows significantly, which is a good hint to look at whether WP-Cron is actually firing.

Fixing it

Do these in order of risk.

Delete expired transients

The safest and usually most effective step. Any half-decent database optimisation plugin does this, or you can do it directly. Every transient has a paired _transient_timeout_ entry holding its expiry, so expired ones are identifiable rather than guessed at.

This alone regularly takes a bloated wp_options table down by half or more.

Remove orphaned options

Cross-reference the largest autoloaded options against your installed plugin list. Anything whose prefix matches a plugin you no longer have is a candidate.

Take a backup first. The failure mode here is deleting something still in use because the option prefix did not obviously match its owner.

Switch large in-use options off autoload

For options that are legitimately large and legitimately needed, but not needed on every request:

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

The option remains fully available via get_option() — WordPress simply fetches it on demand instead of preloading it. For an option only read on one admin screen, that is a straight win.

Be careful with anything read on the front end during a normal page render, since you would trade one autoload query for a per-request individual query. Options only touched in wp-admin are the safe candidates.

Add a persistent object cache

If your host supports Redis or Memcached, a persistent object cache changes the economics entirely: autoloaded options get served from memory rather than re-queried on every request. It does not make the bloat disappear, but it dramatically reduces what the bloat costs you.

Verify with a before and after

This is the part people skip, and it is the part that tells you whether any of it worked.

Record the numbers before you start: total autoloaded size, entry count, and a timed loopback request to the site. Then re-measure after. Without a baseline you are relying on whether the admin feels faster, which is not a measurement — expectation bias after an hour of database work is substantial.

A typical result on a badly bloated site looks like autoload dropping from around 2.4 MB to under 500 KB, with admin page loads improving by well over a second. That is a large enough change to be unambiguous.

Talos measures all of this in one pass — autoload size and entry count, the largest offenders, expired transient ratio, plus cache state and loopback timing — and can diff two diagnostic snapshots so the before-and-after is a concrete comparison rather than an impression.

Keeping it clean

Autoload bloat is not a one-time fix, because the cause is ongoing: you will keep installing and removing plugins, and each cycle leaves residue.

The realistic approach is a recurring check rather than a resolution. A monthly read-only report on autoload size, entry count and the top offenders takes no effort once it exists, and it turns a slow degradation you would not otherwise notice into a number you can watch. When it drifts back over a megabyte, you already know which options to look at.