Autoloader
Optimizer

How the Autoloader Optimizer Works

The Autoloader Optimizer analyzes your site's autoloaded options and recommends safe optimizations. It classifies every option into categories, identifies candidates for optimization, and provides a restore mechanism in case anything goes wrong.

1. Health Check — Scans every autoloaded option and classifies it into one of six categories
2. Plugin Detection — Uses WordPress metadata (TextDomain + folder name) to match options to plugins with high accuracy
3. Learning Mode — Optional observation period tracks which options are actually accessed before making changes
4. Optimization — Creates a backup, then disables autoload on flagged candidates. No data is ever deleted.

Step 2: Plugin Detection — How Prefixes Work

The hardest part of option analysis is correctly identifying which plugin created which option. The module uses WordPress's get_plugins() API to retrieve all installed plugins with their full metadata, including TextDomain.

Generating Prefixes

For each plugin, we generate multiple possible prefixes:

1. Folder-based prefix — The plugin folder name with underscores (e.g., advanced-caching becomes advanced_caching_)
2. TextDomain prefix — The plugin's declared TextDomain, if different from the folder name

This dual-prefix approach handles common WordPress naming patterns where the folder uses dashes and the TextDomain uses underscores, or vice versa.

Before v1.1.18: The Prefix Problem

After v1.1.18: TextDomain-Based Detection

The current implementation solves this by:

1. Reading the full plugin metadata, including the declared TextDomain from the plugin header
2. Using both the folder name and the TextDomain to generate prefixes
3. Verifying the plugin's active status against WordPress's official active_plugins list
4. Only classifying an option as "inactive plugin" if we're very confident the plugin is actually inactive

This dramatically reduces false positives. We now correctly identify that Yoast SEO (folder: wordpress-seo, TextDomain: wordpress-seo) matches wordpress_seo_, wordpress-seo_, and wpseo_ variants by checking plugin headers. The result: we almost never accidentally flag active plugin options as orphaned.

Step 4: Optimization

Once you've reviewed the analysis and identified candidates, the module applies the optimization:

1. Backup creation — A complete backup of the options table is created and stored as an option in the database
2. Autoload flag update — For each selected candidate, the autoload column is set from 'yes' to 'no'
3. Verification — The module displays a summary of what changed
4. Monitoring — After optimization, you can monitor whether the site still functions correctly

Safety Measures

The Autoloader Optimizer is built with several layers of safety:

Safe Options List

A curated list of WordPress core options that are never flagged for optimization. This protects essential WordPress functionality regardless of size or origin.

Prefix-Based Plugin Matching

Uses WordPress's official plugin metadata (TextDomain, folder name) to identify which plugin owns which option. Matched against the official active_plugins list to avoid false positives.

Conservative Categorization

If there's any doubt about an option's origin or safety, it's placed in the "Unrecognized" category rather than being flagged for automatic optimization.

Backup Before Optimization

A complete snapshot of all autoload options is created and stored in the database before any changes are made.

One-Click Restore

If anything goes wrong, you can restore the backup with a single click. All autoload settings revert to their previous state.

Developer Filter Hook

Developers can register custom options that should never be autoload-disabled. Use the wpmultitool_autoload_candidates filter to modify the candidates list before optimization is applied:

add_filter('wpmultitool_autoload_candidates', function($analysis) {
    // Protect specific options from being optimized
    $analysis['candidates'] = array_diff($analysis['candidates'], [
        'my_critical_option',
        'another_important_one',
    ]);
    return $analysis;
});

Even if an option matches a bloat pattern or comes from an inactive plugin, the filter allows you to exempt it from optimization.

Data Preservation

Options are never deleted. Only the autoload flag is modified. The data remains fully accessible to plugins and code that request it.

Monitoring and Troubleshooting

After Optimization: What to Monitor

1. Page load times — Use Google PageSpeed or WebPageTest to measure before/after
2. Database queries — Check your slow query log for any new slow queries
3. Functionality — Test critical user workflows (checkout, forms, admin operations)
4. Error logs — Watch wp-content/debug.log for any new warnings or errors

If Something Breaks

1. Go to WP Multitool → Autoloader Optimizer → Status
2. Click "Restore Backup"
3. All autoload flags revert to their previous state
4. Investigate which optimization caused the issue
5. Use the Developer Filter Hook to protect that specific option
6. Re-apply optimizations without the problematic option

Measuring Your Autoload Size

-- Before optimization (check current autoloaded size)
SELECT SUM(CHAR_LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on');

-- After optimization (verify the reduction)
SELECT SUM(CHAR_LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on');

FAQ

Will this break my site?

No. The Autoloader Optimizer only changes the autoload flag, never deletes any data. When a plugin or WordPress core requests an option that's no longer autoloaded, WordPress will still load it from the database — it just won't be loaded on every single request. Additionally, a full backup is created before optimization, and you can restore it with one click if anything unexpected happens.

Why aren't unrecognized options optimized automatically?

Because we can't verify their source. They might be options from your active theme (which uses non-standard prefixes), options from a must-use plugin in /wp-content/mu-plugins/, custom options from your own code, or options from a plugin with non-standard naming. Automatically optimizing unrecognized options would risk breaking functionality we don't fully understand. We display them for your review instead.

What about plugins with non-standard prefixes?

Since v1.1.18, we use the TextDomain from the plugin header to generate additional prefixes, which captures most non-standard naming. However, some plugins use prefixes that bear no relation to their name (e.g., custom abbreviations in legacy code). For these cases, you can use the Developer Filter Hook to protect the options, or manually inspect the option and make your own decision.

Why does the plugin still create options for features I'm not using?

Most WordPress plugins create all their option keys during installation, regardless of which features you enable. This is simpler than dynamically checking for feature activation. The Autoloader Optimizer helps mitigate this by not autoloading options from deactivated plugins or features you're not currently using.

How much can I realistically save?

It depends on your site's plugin ecosystem. A typical site with 8–12 plugins can expect a 100–300KB reduction per request. A WooCommerce site with 15–20 plugins can see 500KB–2MB. A heavily bloated site with 30+ plugins and years of history can see 2–5MB+ per request.

What happens if a plugin is reactivated after I've disabled autoload for its options?

The options will still function normally. WordPress will load them on-demand when the plugin requests them. If you want those options autoloaded again, you can use the Restore Backup function to revert all changes, or manually re-enable autoload for specific options in the database.

Does this affect transients or cron events?

Transients and cron schedules stored in wp_options are candidates for optimization, but they're typically accessed only when needed. The module flags large ones for your review. You can protect them using the Developer Filter Hook if you prefer they remain untouched.