Autoloaded options: the silent tax on every page load

Every row in your wp_options table has an autoload column set to either yes or no. Every row marked yes gets pulled into memory by wp_load_alloptions() on every single page load, before WordPress has decided what page it is even rendering. It does not matter if the request is your homepage, a REST API call, or a cron job; that row loads anyway. This is the closest thing WordPress has to a fixed tax: it is paid on every visit, whether the visitor benefits from it or not.

On a healthy site this costs almost nothing, a few hundred kilobytes unserialized in a single cached query. On a site that has run for a few years with a rotating set of plugins and a page builder, it can quietly grow into megabytes of dead weight that every visitor pays for on every page.

What does autoload='yes' actually do?

WordPress needs a handful of core settings, like the site URL and the active theme, on every request, so instead of running a separate query for each one, it runs a single query that grabs every autoloaded row at once and caches the result for the rest of that request. That design is efficient when the autoloaded set is small. The problem is that the cost scales with the total serialized size of every autoloaded row combined, not with how many of them your page actually needs. A 3MB autoload set is unserialized in full on every uncached request, even one that only reads two of those rows.

How does it grow without anyone noticing?

Nobody sets out to bloat autoload. It accumulates from three habits that are each individually reasonable and collectively expensive.

1. 1.Transients marked autoload by mistake. A transient is meant to expire and be read occasionally, not on every request. Some plugins store transients with autoload left on, which means temporary, disposable data sits in the expensive path permanently.
2. 2.Page builders dumping large JSON blobs. Visual page builders often store an entire page's layout as one serialized option, and some autoload it so the builder can read it quickly in the editor, forgetting that the same row now loads on the public-facing pages too.
3. 3.Plugins you deactivated but never removed. Deactivating a plugin stops its code from running, but its options usually stay behind with autoload still on, so the tax keeps being paid for a feature nobody is using anymore.

Finding the worst offenders

Start with the total, run against your database:

SELECT SUM(LENGTH(option\_value)) / 1024 AS autoload\_kb
FROM wp\_options WHERE autoload = 'yes';

Over 1024 (1MB) is worth investigating. Over 3072 (3MB) is roughly an estimated 200ms penalty on every uncached page load. Then find which specific rows are responsible:

SELECT option\_name, LENGTH(option\_value) AS bytes
FROM wp\_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;

The option name usually tells you which plugin owns the row. A prefix you no longer recognize, or a _transient_ row sitting near the top of that list, is your starting point. Our [expired transients fix guide](/fixes/flush-expired-transients) covers the transient side of this in detail if that is where most of your size is concentrated.

Fixing it safely

Do not delete rows straight out of the database because they look large. Some options are large for a legitimate reason, and a plugin can behave unpredictably if it expects a row to exist and finds it missing. Work through it in order: identify which plugin owns the option, check whether that plugin is still active and whether the feature is still in use, and only then decide between three outcomes. If the plugin is abandoned or unused, remove it properly through its own deactivate-and-delete flow so it cleans up after itself. If the plugin is active but the option is rarely read (not on every page, just occasionally in the admin), it is a candidate to switch to autoload='no' with WP-CLI. If the option is genuinely read on most page loads, leave it on autoload; that is what the mechanism is for. Our [reduce autoload size fix guide](/fixes/reduce-autoload-size) walks through the full decision process with the specific WP-CLI commands. Take a full backup first; a backup turns a risky change into a reversible one.

Run it on your site

The two queries above take under a minute and will tell you exactly where you stand. If you would rather not run raw SQL, BoltAudit's free Local Audit measures your total autoload size and flags the largest individual rows as part of its read-only database checks, with nothing changed automatically and nothing leaving your site.

Key takeaways

• Autoload='yes' rows load into memory on every page load, regardless of whether that page needs them.
• It grows silently from mismarked transients, page builder blobs, and options left behind by deactivated plugins.
• Identify who owns an option before you touch it. Remove abandoned plugins properly, and only flip autoload to no for rows that are genuinely rarely read.

Frequently asked

What does autoload='yes' actually mean?

It means WordPress loads that row into memory via wp\_load\_alloptions() on every single page load, whether the current request needs it or not. The result is cached for the rest of that request, but the initial load happens every time regardless of which page or plugin is running.

Is it safe to set autoload to no for every large option?

No. Some large options, such as active theme mods or certain plugin settings, are genuinely read on most page loads and belong on autoload. Check what reads the option, and how often, before changing it, rather than switching every large row at once.

Can I just delete unused autoloaded options?

Not blindly. Identify which plugin owns the option first, usually from its name prefix, and prefer that plugin's own deactivate-and-delete flow over a raw database delete, since some plugins expect their options to exist even when the value is empty.

How big is too big for autoload?

Over 1MB total is a real problem worth investigating. Over 3MB is roughly an estimated 200ms penalty added to every uncached page load, since that entire payload is unserialized into memory before your page starts rendering.

Not sure how large your autoload set is? [The free Local Audit](/features) measures it in about a minute.

wp\_options Autoload Database

BA

BoltAudit team

Builders and operators who name the exact bottleneck slowing a WordPress site and rank every fix by visitors recovered.

[Talk to us](/contact)