Logo
WP Fix by Blimx

The Autoload Trap — Detecting and Cleaning Bloated WordPress Options

Actualizado:
PerformanceDatabase

The hidden cost of WordPress options

Every WordPress request starts with a single query:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

This loads all options marked autoload='yes' into memory. The intent: store frequently-needed configuration once per request rather than querying per option.

The problem: plugins write data to options carelessly. Over years, the autoload payload grows from a healthy 200KB to a catastrophic 20MB. Every request now loads 20MB of mostly-useless data from MySQL into PHP, blowing memory and slowing every page.

This article is the diagnostic and cleanup playbook for autoload bloat.

How to measure your autoload size

The single most important query for WordPress performance:

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

Healthy: under 1MB, fewer than 200 options. Concerning: 1-5MB, 200-500 options. Catastrophic: 5MB+, 500+ options.

The biggest offenders

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

The output shows your top 30 autoload options by size. Patterns we have seen:

Pattern 1 — Orphan plugin transients

_transient_timeout_X     350 KB
_transient_X             280 KB

If you removed a plugin but its transients were not cleaned up, they linger forever.

Pattern 2 — Stale plugin caches

wpforms_cached_forms      4500 KB
elementor_template_data   3200 KB

Plugin developers shouldn't store this kind of data autoloaded. But many do. Years of accumulation creates massive autoload entries.

Pattern 3 — Disabled plugins left behind

some_old_plugin_settings  1200 KB
some_old_plugin_data      900 KB

When you deactivate (not delete) a plugin, its options remain. They keep loading on every request, wasting time.

Pattern 4 — Backup plugin data

backwpup_jobs             8000 KB
ai1wm_export_status       5000 KB

Backup plugins sometimes store backup metadata in autoload. Massive.

Why autoload bloat slows everything

Loading 20MB from MySQL takes 200-500ms even on fast hardware. Multiply by 1000 visits per hour and you have:

  • 200,000-500,000ms of needless time spent per hour
  • High MySQL CPU just serving the same options repeatedly
  • PHP memory pressure (the data sits in memory for the full request)
  • Cache misses (object cache populates with useless data)

In aggregate, autoload bloat is often the single biggest cause of slow WordPress sites. We've seen TTFB drop from 2.5s to 400ms after a 10-minute autoload cleanup.

The cleanup procedure

Step 1 — Backup the database

wp db export pre-autoload-cleanup.sql

Non-negotiable. Some "useless" options may be needed by code you don't realize is running.

Step 2 — Identify cleanup candidates

-- Top 50 autoload entries by size
SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS size_kb
FROM wp_options 
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 50;

For each large entry, answer: 1. Is the plugin still active? If no → option can probably be deleted 2. Is it a transient? If yes → can be deleted (will regenerate if needed) 3. Is it documented somewhere? Search Google for wp_options "<option_name>"

Step 3 — Delete expired transients

-- Delete expired transients
DELETE FROM wp_options WHERE option_name LIKE '\_transient\_timeout\_%' AND option_value < UNIX_TIMESTAMP();

DELETE FROM wp_options WHERE option_name LIKE '\_transient\_%' 
  AND option_name NOT IN (SELECT * FROM (SELECT REPLACE(option_name, '_transient_timeout_', '_transient_') FROM wp_options WHERE option_name LIKE '\_transient\_timeout\_%') a);

Or with WP-CLI:

wp transient delete --expired

Step 4 — Remove options from deactivated/uninstalled plugins

Get a list of all plugins ever installed:

ls wp-content/plugins/

For each plugin, identify its options:

SELECT option_name FROM wp_options WHERE option_name LIKE '<plugin_prefix>%';

If the plugin was uninstalled but options remain, delete them:

DELETE FROM wp_options WHERE option_name LIKE 'oldplugin_%';

Step 5 — Switch large autoload entries to autoload=no

For options that you need to keep but don't load on every request:

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

The data is preserved; it just won't load on every request. The plugin that needs it will fetch it explicitly when needed.

Candidates for autoload=no: - Backup plugin metadata - Old plugin caches - Plugin export/import data - Analytics-style aggregates

Step 6 — Re-measure

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

Goal: under 1MB total, under 300 options.

Persistent object cache changes the equation

If you have Redis or Memcached configured as a persistent object cache, autoload bloat hurts less — the options are cached after first load.

But: persistent object cache doesn't help on the first request after cache clear, and it doesn't help when cache is evicted under memory pressure. So autoload bloat still hurts during traffic spikes and cache clears.

Recommended setup:

// wp-config.php
define('WP_CACHE', true);
define('WP_CACHE_KEY_SALT', 'yoursite-prefix');

Install Redis Object Cache plugin. Configure Redis with 256MB+ memory.

Common mistakes during autoload cleanup

  • Deleting options without backup — some plugins corrupt without their config; backup first
  • Setting autoload=no on critical options — like siteurl, home, wp_user_roles; these MUST stay autoloaded
  • Trusting "Optimize Database" plugins blindly — they often delete too aggressively
  • Not measuring before/after — you can't tell if the cleanup helped without numbers

Monitoring autoload growth

Set up a weekly check:

# crontab
0 9 * * 1 wp option list --autoload=on --format=count >> /var/log/autoload-count.log
0 9 * * 1 wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) FROM wp_options WHERE autoload = 'yes'" >> /var/log/autoload-size.log

If size grows by 500KB+ in a week, investigate what plugin added so much.

Common offending plugins (2026)

Plugins we routinely see causing autoload bloat:

  • WPForms — caches form data autoloaded
  • BackWPup — backup job metadata
  • Yoast Premium — internal caches
  • WooCommerce extensions — some store transient-like data autoloaded
  • Old Visual Composer / WPBakery — large theme settings

Audit options from these plugins quarterly.

When to call a specialist

If your autoload is 10MB+ or you see TTFB consistently above 1500ms despite caching, the autoload trap is almost certainly involved. A full database performance audit usually finds 2-5 separate issues; total cleanup takes 1-3 hours.

Speed recovery diagnostic for site-wide performance. For database-specific work see database optimization.