WordPress Autoloaded Options: What the Site Health Warning Misses

By Greg Nowak. Last updated 2026-10-30.

A WordPress Site Health warning about autoloaded options can leave you with an awkward decision: something may be affecting performance, but the dashboard does not tell you what is safe to change.

For a business website, the useful next step is to identify which settings are loading unnecessarily, trace the code responsible, and test a targeted fix. That gives owners and agency teams a manageable piece of maintenance with clear acceptance criteria.

What the warning actually measures

Autoloaded options are settings WordPress loads together so they are available without fetching each one separately. This is useful for frequently accessed configuration. It becomes wasteful when that collection includes large reports, old plugin data, or settings used on one occasional admin screen.

The current Site Health check reports the option count and combined size. Its default critical threshold is 800000 bytes, with the warning triggered at or above that limit. The count itself does not trigger the warning.

That threshold is an investigation prompt, not a performance measurement. Going below it does not prove the site is fast; exceeding it does not identify the cause of a slow checkout.

Caching also matters. WordPress caches the autoload collection, so it does not necessarily query the database for it on every request. A full-page cache can bypass WordPress execution altogether. Focus performance comparisons on requests that actually run WordPress, including logged-in and transactional journeys.

Start with an inventory, not a delete button

Before changing data, take a restorable database backup and use staging to investigate. Record the current total, largest options, and representative response times. This creates a baseline for deciding whether the work helped.

With WP-CLI available, run this from the WordPress installation directory to list the 20 largest values in the loaded collection, in bytes:

wp eval '
$options = wp_load_alloptions();
uasort( $options, static function ( $a, $b ) {
    return strlen( (string) $b ) <=> strlen( (string) $a );
} );
foreach ( array_slice( $options, 0, 20, true ) as $name => $value ) {
    printf( "%8d %s\n", strlen( (string) $value ), $name );
}
'

This lists names and value sizes without printing their contents. It is an inventory, not a PHP memory measurement. On multisite, select the intended site using WP-CLI’s --url argument.

For each large entry, identify its plugin, theme, or custom-code owner. Search for both reads and writes, including dynamically constructed names. An inactive plugin is a clue, not proof that its settings are disposable: they may be retained for reactivation or used by an integration.

Choose the fix by how the data is used

Disabling autoload keeps the setting available through normal option retrieval. It can shift work to the requests that need it, which is why switching everything off is a poor default.

Modern WordPress helps, but does not clean up old decisions

WordPress 6.6 introduced a default 150000-byte size heuristic for automatically determined autoloading. It also introduced database states such as on, off, auto, auto-on, and auto-off. The official Options API change notes explain these safeguards.

Existing rows were not automatically rewritten. An upgrade therefore does not guarantee that legacy bloat disappears. Audit SQL that checks only autoload = 'yes' also misses modern autoload states.

For maintained code, use explicit boolean intent where usage is known: true for broadly needed settings and false for narrowly used ones. Passing the strings yes and no into the APIs has been deprecated since WordPress 6.7.

Change the flag and fix the save logic

There is an easy implementation trap: update_option() cannot change an existing option’s autoload flag unless its value also changes. Use it in the normal save path when saving a changed value:

update_option( 'my_option', $value, false );

For a flag-only correction, wp_set_option_autoload_values() changes the autoload state without rewriting the payload and handles the related option-cache updates:

wp_set_option_autoload_values( array(
    'my_option' => false,
) );

Replace the example name with a reviewed option. Apply this as a controlled maintenance change or migration. Then correct the owning save logic so a settings save, scheduled task, or deployment does not reverse the decision. For third-party plugins, seek a supported fix rather than editing plugin files that updates replace.

Verify the business workflows and the result

Change a small, documented batch, then repeat the inventory and performance checks under comparable cache conditions. Test login, forms, checkout where relevant, affected admin screens, and scheduled jobs. Save the owning plugin’s settings again and check whether the autoload state survives.

The handover should record what changed, why it was safe, how to reverse it, and who owns the lasting code fix. Raising the Site Health threshold only changes the alert; it does not reduce the loaded data.

If your team needs help tracing unfamiliar options or coordinating a safe release, Greg can audit the collection, implement targeted changes, and document the outcome. Talk to Greg about your WordPress site.

Related on GrN.dk

• Prompt Cache Write Costs: Check What Your Workflow Actually Reuses
• WordPress Plugin Updates: What the Six-Hour Cooldown Can’t Check
• Can’t Publish in WordPress? Fix the Invalid JSON Response Without Guesswork

Need help with this kind of work?

Discuss a WordPress autoload audit with Greg Get in touch with Greg.

Sources

• WordPress Site Health: get_test_autoloaded_options()
• WordPress: wp_load_alloptions()
• Options API: Disabling autoload for large options
• WordPress: update_option()
• WordPress: wp_set_option_autoload_values()