The autoload_size check measures the aggregate weight of every row in wp_options flagged autoload='yes', not any single option. That total dictates how much memory WordPress lifts off the database on every request before a single line of plugin code executes. A healthy site stays below 500KB; a tolerable one stays under 1MB; anything above 1.5MB is an active performance regression.
Why this matters
The query that hydrates $alloptions runs in WordPress bootstrap, before everything else. That means every request - including extremely short endpoints like /wp-json/wp/v2/posts/123, admin-ajax.php?action=heartbeat, and any plugin AJAX that loads a modal - pays the cost. On modern MySQL on SSD, a SELECT returning 1MB of data takes roughly 30-80ms; 2MB pushes 80-180ms; 5MB lands at 250-500ms. PHP's unserialize on a deeply nested array adds another 30-50% on top.
Autoload weight stacks on every Core Web Vital: it raises TTFB (which feeds LCP, target ≤ 2.5s), and it inflates per-action latency in WP-Admin (which feeds INP). A WooCommerce store with 3MB of autoload sees 1.5-second cart-fragment AJAX responses - bad enough that shoppers abandon checkout while it spins.
How to detect
The standard total query:
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS total_mb,
COUNT(*) AS rows
FROM wp_options
WHERE autoload = 'yes';And the breakdown by heaviest entries:
SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 30;Query Monitor surfaces the figure on every page load in its toolbar. WP-CLI's wp option list --autoload=on --fields=option_name --format=count gives the row count, and with --format=csv you can sum sizes locally. Advanced Database Cleaner offers a visual breakdown for non-CLI users.
How to fix
Cleanup follows three buckets. (1) Orphan options - left behind by a plugin you uninstalled months ago. Safe to DELETE outright. (2) Active-plugin options that grew beyond intent - usually logs, history tables, or transients written outside the Transient API. Either flip autoload to no or reset the value through the plugin's settings. (3) Legitimate large options - rewrite_rules on a 10K-post site, or cron with 200 scheduled jobs. They have to stay, but they almost always tolerate autoload=no without breaking anything.
-- delete an orphan option
DELETE FROM wp_options WHERE option_name = 'OPTION_NAME';
-- remove from autoload without deleting
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'OPTION_NAME';After either change, run wp cache flush if you use Redis or Memcached - otherwise the old $alloptions array stays cached and the win is invisible until expiry.
Common mistakes
The most damaging mistake is removing autoload from core options (siteurl, active_plugins, template). It creates dozens of separate queries per request and slows the site more than the original bloat. The second mistake is deleting an option that an active plugin owns - it just regenerates the row, sometimes with a default value that grows faster than the one you removed. The third is forgetting OPTIMIZE TABLE wp_options after deletes; InnoDB does not shrink the physical file on its own, so backups stay heavy until you reclaim the space.
Verifying the fix
Re-run the SUM query and confirm you crossed below 1MB. PageSpeed Insights should show 150-400ms shaved off TTFB. WebPageTest waterfall comparisons (capture a before and after) make the gain obvious - the server-response bar shrinks. If a page cache (WP Rocket, LiteSpeed Cache) is in front of the site, cached visitors will not feel anything, but AJAX endpoints and admin requests will respond noticeably faster the moment you deploy.