Autoload Bloat: The Silent WordPress Performance Killer

Autoload bloat is when your WordPress wp_options table loads megabytes of data into memory on every uncached request, most of which the page never uses. It is one of the most common causes of a slow WordPress site, and it is almost never the first thing anyone suspects. It shows up on most slow sites we audit, hiding in plain sight while the team blames images or plugins.

Picture a chef who, before cooking any dish, drags every ingredient in the entire pantry out onto the counter, then puts most of them back unused. That is autoload. WordPress does a version of this on every page load, and when the pantry has quietly filled with junk, the chef wastes real time on every single order.

This guide explains what autoload actually does, how it gets out of hand, the one query that reveals it, and how to shrink it safely without breaking your site.

What does "autoload" actually do in WordPress?

WordPress reads the wp_options table on every uncached request. By default, every option marked autoload = 'yes' is loaded into memory at the very start of the bootstrap, before WordPress knows what the page even needs. This is useful for a handful of core settings like siteurl and blogname that nearly every page uses.

It becomes a problem when a plugin decides to autoload several megabytes of data it does not need on every page, such as cached API responses, session data, or a page builder's preview JSON. WordPress dutifully loads all of it, every time, whether the current page uses it or not.

Here is the rough scale to keep in mind:

• Under 1MB: healthy. This is where you want to be.

• Past 5MB: every uncached page is paying a measurable speed tax.

• Past 20MB: autoload is very likely the single biggest bottleneck on the site.

How autoload bloat gets out of hand

Bloat builds up quietly over months. The usual culprits:

• A plugin is installed, dumps a config blob into wp_options with autoload=yes, and is later uninstalled, but the row is left behind. Orphaned rows like this never clean themselves up.

• A page builder caches its preview JSON in autoload because it is convenient for the developer.

• A logging plugin writes its rolling buffer to options because the author did not know about transients (transients are WordPress's proper home for temporary data, with a built-in expiry).

• Old transients without expiry dates pile up in the options table indefinitely.

None of these announce themselves. The table just keeps growing, and every uncached request gets a little slower.

How to spot autoload bloat (one query)

You can measure your total autoload size with a single SQL query. Run this in phpMyAdmin, Adminer, or any database tool your host provides:

SELECT
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';

This returns your total autoloaded data in megabytes. Anything over 1MB warrants a look. Anything over 5MB is a real problem worth fixing soon.

To see exactly which options are the heaviest, run this:

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

This lists your 20 largest autoloaded options in kilobytes, biggest first. That list is your fix list.

[INSERT IMAGE HERE using the orange Image button: URL https://boltaudit.com/og-default.svg, alt "WordPress autoload bloat shown as a bloated wp_options table". Swap the URL for your real thumbnail before publishing.]

Before you touch anything: back up first

The options table runs your whole site, so a careless edit here can break things, and on a WooCommerce store a bad change can interrupt checkout and cost real orders. The rule is simple: back up your database before changing or deleting any rows. A backup turns a risky change into a reversible one.

Reading the table (the queries above) is completely safe. It is only writing and deleting that need a backup.

How to fix autoload bloat safely

Work through the heavy list you generated, one row at a time:

1. Identify the heaviest autoloaded options using the second query above. Recognize what each one is before acting; a quick search of the option_name usually tells you which plugin owns it.

2. For any row that does not need to load on every request, switch it from autoload = 'yes' to autoload = 'no', or move the data to a transient with a real expiry. The data stays available; it just stops loading on every single page.

3. Delete orphaned rows left behind by plugins you have already uninstalled. Confirm the owning plugin is truly gone before deleting.

The payoff is direct: trimming autoload usually drops TTFB (time to first byte, how long the server takes to start replying) by 100 to 400ms on cold, uncached requests, without touching a line of frontend or backend code.

How BoltAudit finds autoload bloat for you

If hand-writing SQL is not your idea of a good time, you can have the whole thing diagnosed automatically.

[Make the word BoltAudit below a link with the chain/link button: https://wordpress.org/plugins/boltaudit/]

BoltAudit is a free, AI-powered WordPress performance audit plugin that runs more than 200 read-only checks across frontend, backend, database, and infrastructure in under 90 seconds. Its database-layer collector flags bloated autoloaded options directly and ranks them by impact, so you get the same fix list the second query produces, without writing any SQL. Read-only means it never writes to your database or deletes anything, so it is safe to run on a live production or WooCommerce site. Audits are located under Tools> BoltAudit in your WordPress admin.

Keep autoload lean over time

Autoload creeps back as you add and remove plugins. A light habit keeps it in check:

• Check your autoload total after installing or removing any plugin.

• Re-check monthly, since orphaned rows and stale transients accumulate quietly.

• Always back up before changing or deleting options rows.

Run it on your site

If your site feels slow on the first, uncached load and you cannot explain why, autoload bloat is a prime suspect. Install BoltAudit free, run a Local Audit from Tools, then BoltAudit, and let it tell you in seconds whether your options table is the problem and exactly which rows to trim.