The Autoloaded Option That Slows Every Single Request
WordPress loads every autoloaded option on every single request, in one query, into one cache entry. Not the ones the page needs. All of them. This is the slow site problem that never shows up in a plugin audit, because nothing is broken.
What Actually Happens
On each request WordPress runs a single query for every row in wp_options where
autoload is yes, and unserialises the lot into the alloptions cache. Your
homepage pays for it. So does robots.txt, every admin-ajax call, and every REST request.
The cost is not the query. It is the size. A plugin that parks a 4 MB cached API response, or an activity log, or a licence payload, in an autoloaded row has added that much unserialising to every request your server handles. Object caching helps and does not fix it: something still has to build that cache entry, and it is invalidated every time any option is written.
Finding It Takes One Query
Site Health will tell you there is a problem. It will not always tell you which row. This will:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;In our experience the top of that list is nearly always three things: a plugin caching a remote response it should have put in a transient, a log table that was implemented as an option because it was quicker to write, and something left behind by a plugin that was deleted two years ago.
WordPress 6.6 added a Site Health check that raises a critical issue once your autoloaded options pass 800 KB in total. That is a useful alarm, not a target: a single 300 KB row loaded on every request is already worth fixing even though it never trips the warning.
Fixing It Without Breaking Anything
Since WordPress 6.4 there has been a proper function for this, so you do not need to touch the database directly:
wp_set_option_autoload( 'some_plugin_cached_feed', false );The option still exists and still reads exactly as it did. It is simply fetched when something asks for it instead of on every request. If the plugin reads that option on every page load anyway, you have gained nothing and you should say so rather than claim a win.
Since 6.6, core will also refuse to autoload anything larger than 150,000 bytes when it is written, unless the value is filtered. That protects you from new offenders. It does not clean up the rows that were already there before you upgraded, which is where the weight usually is.
The Part That Is Not About Options
The reason this problem survives is that nobody owns it. It is not a bug in any one plugin, it never appears in an error log, and every individual row looks reasonable. It only exists in the total, and the total is the one number nobody looks at.
When we take over a site, this query is one of the first things we run, before anything is optimised or replaced. It is five minutes of work and it is regularly the single largest thing slowing the site down.