Autoload bloat is the silent WordPress killer

This one shows up on most slow sites we audit, and it's never the suspect when the team starts looking.

What 'autoload' actually does

WordPress reads wp_options on every uncached request. By default, every option with autoload = 'yes' gets loaded into memory at the start of the bootstrap. Useful for things like siteurl and blogname. Catastrophic for plugins that decided to autoload 4MB of session data.

A healthy autoload total is under 1MB. Past 5MB, every uncached page is paying a measurable tax. Past 20MB, it's usually the bottleneck.

How it gets out of hand

• A plugin gets installed, dumps a config blob into wp_options with autoload=yes, and gets uninstalled — the row stays.
• A page builder caches its preview JSON in autoload because it's convenient.
• A logging plugin writes its rolling buffer to options because the author didn't know about transients.
• Old transients without expiries pile up indefinitely.

How to spot it

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

Anything over 1MB warrants a look. Anything over 5MB is a real problem.

How to fix it

1. Identify the heaviest autoloaded options:

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

1. For each row that doesn't need to load on every request, switch it to autoload = 'no' or move the data to a transient with a real expiry.
2. Delete orphaned rows from uninstalled plugins.

BoltAudit's database-layer collector flags these directly and ranks them by impact. The fix usually drops TTFB by 100-400ms on cold requests — without touching frontend or backend code.