The Biggest Autoload Option: Find and Neutralize the Single Worst Offender

This check flags a single row in wp_options marked autoload='yes' that weighs hundreds of kilobytes - sometimes several megabytes. The aggregate total may look fine, but one outlier hurts every request: each PHP worker has to load it, run unserialize, and hold a copy in memory. Identifying that lone offender is usually the cheapest performance win on the database side.

Why this matters

One 2MB row on a typical site adds 100-200ms to every TTFB. Multiplied across the 50+ requests of a single page load (HTML, block REST endpoints, wishlist AJAX, heartbeat), that is 5-10 seconds of cumulative MySQL and PHP work spent on a single resource. In the post editor, a 5MB row can stretch INP from 100ms past one full second - well beyond the 200ms Core Web Vitals threshold.

Common culprits cluster into three buckets. Cache or log a plugin forgot to close: keys like action_scheduler_lock, wpcf7_recent_history, jetpack_sync_settings_data, or a tagging plugin's append-only log. Leftover data from a removed plugin: the option survived an uninstall that skipped cleanup. A legitimate option that grew unexpectedly: rewrite_rules on a site with thousands of categories, or a theme-builder configuration where Elementor, Bricks, or Divi serializes everything into one giant blob.

How to detect

RankPlus already shows you the option name. To repeat the lookup manually:

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

Search the option name together with wordpress on Google - the top result almost always reveals the owning plugin. Before you delete anything, peek at the contents with SELECT option_value FROM wp_options WHERE option_name = '...' LIMIT 1;. A nested log array looks completely different from a static config blob, and that tells you which fix to apply.

How to fix

If you confirmed the plugin is gone, drop the row outright:

DELETE FROM wp_options WHERE option_name = 'OPTION_NAME';

If the plugin is still active and this is a log or cache, look for a "Clear log" or "Disable history" toggle in its settings. That is usually the right answer - stop the growth at the source instead of fighting autoload.

If the option is legitimate but does not need to be available on every request, switch it off autoload:

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'OPTION_NAME';

After any change, flush object cache (Redis/Memcached) and page cache (WP Rocket, LiteSpeed Cache) so cached visitors see the new state on their next request.

Common mistakes

Do not delete options whose names you have not researched. Some critical security keys look generic (auth_key, plugin secret_keys). Do not flip autoload to no without checking the consuming code: if a plugin reads the option through get_option() on every page load, removing autoload spawns a fresh SELECT each request - frequently worse than the original bloat. And do not skip the backup. Direct edits on wp_options deserve a mysqldump first, every single time.

Verifying the fix

Run the detection query again - the heaviest option should now sit below 100KB, or at least be noticeably smaller. Open Query Monitor on the front page and check the autoload weight; the improvement should be obvious. PageSpeed Insights should report 50-200ms TTFB reduction from this single change. If the offender was a fast-growing log, revisit a week later - some plugins refill the row almost immediately.