WordPress autoloaded options: measure and review wp_options

Short answer: WordPress autoloaded options are rows in wp_options that WordPress loads into the alloptions array during a normal request. Measure the core autoload set, identify the largest rows and their owners, then disable autoload only for options that are not needed broadly.

What WordPress autoloaded options do

WordPress does not fetch every option with a separate query. The core wp_load_alloptions() function (opens in a new tab) first checks the alloptions cache entry in the options cache group. If that entry is unavailable, it selects the options whose autoload values are considered loadable, builds one array, and caches that array as alloptions.

Without a persistent object cache, the default WordPress object cache lasts only for the current request. A new PHP request therefore has to rebuild the cache when wp_load_alloptions() runs. With a persistent object cache, the alloptions array can persist between requests as one cache key.

That distinction matters when reading a database profile. A persistent cache can remove repeated database reads for alloptions, but it does not make an oversized array free. WordPress still has to retrieve and work with the cached value when it is needed.

For a wp_options autoload audit, measure what core treats as autoloaded. Do not assume that only rows containing yes count on current WordPress.

What changed in WordPress 6.6

The WordPress 6.6 Options API dev note (opens in a new tab) changed both the stored values and the default decision process. Existing yes and no rows were not migrated, so a current database can contain legacy and newer values together.

The possible values you are likely to see are:

• yes: legacy value that is still treated as autoloaded.
• no: legacy value that is not autoloaded.
• on: an explicit autoload choice of true.
• off: an explicit autoload choice of false.
• auto: no explicit choice, with core deciding the default behavior.
• auto-on: a dynamically determined value that should autoload.
• auto-off: a dynamically determined value that should not autoload.

Since WordPress 6.6, wp_autoload_values_to_autoload() returns yes, on, auto-on, and auto by default. The filter with the same name can remove values from that default set, but it cannot add arbitrary new values.

WordPress 6.6 also changed the default handling of large option values. When WordPress determines autoload automatically, a serialized option value greater than the wp_max_autoloaded_option_size threshold is not autoloaded. The default threshold is 150,000 bytes, and the filter can change it per option. For a new option saved without an explicit choice, a value above that threshold is therefore not autoloaded by default.

This rule does not mean every option larger than 150,000 bytes is forced off. Code that explicitly requests autoloading can still set an option to autoload. The size heuristic applies when WordPress is choosing the default.

WordPress 6.6 also added the Site Health autoloaded options check. Its default threshold is 800,000 bytes through site_status_autoloaded_options_size_limit. Core reports the test as good below that limit and critical at the limit or above.

Treat that value as a Site Health threshold, not as a promise that every site below it is fast. The useful question is which data is loaded on every request and whether that data needs to be there.

How to measure WordPress autoloaded options with SQL

For WordPress 6.6 and later, use the same default values that core treats as autoloaded. Replace wp_options if the site uses a different table prefix.

Start with the total:

SELECT
    SUM(LENGTH(option_value)) AS total_bytes,
    ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS total_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

LENGTH() returns bytes for the stored option value. total_bytes gives you the raw total, while total_kb makes the result easier to scan.

Then list the 20 largest rows:

SELECT
    option_name,
    autoload,
    LENGTH(option_value) AS size_bytes,
    ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size_bytes DESC
LIMIT 20;

This query shows which rows dominate the autoload size. The autoload column also tells you whether each row is legacy, explicitly enabled, or automatically enabled.

These queries mirror the default WordPress 6.6+ autoload values. If the site uses the wp_autoload_values_to_autoload filter to remove a value, core can load a smaller set than this SQL query reports.

How to measure with WP-CLI

WP-CLI provides a quick inventory through wp option list (opens in a new tab). To list option names and stored sizes, run:

wp option list --autoload=on --fields=option_name,size_bytes

Example output, with illustrative values only:

+--------------------------+------------+
| option_name              | size_bytes |
+--------------------------+------------+
| siteurl                  | 28         |
| active_plugins           | 1462       |
| acme_plugin_settings     | 18432      |
| example_builder_cache    | 73120      |
| rewrite_rules            | 41288      |
+--------------------------+------------+

Read size_bytes as the stored size of each option value. A large row is a lead for investigation, not proof that the row is wrong. A settings array used on most requests may be a valid autoload candidate, while a similarly sized admin-only cache may not be.

For the WP-CLI total, run:

wp option list --autoload=on --format=total_bytes

There is an important difference between current WP-CLI output and the WordPress 6.6+ SQL above. Current WP-CLI maps --autoload=on to rows with autoload='on' or autoload='yes'. It does not include auto or auto-on.

The command also excludes transient rows by default. Because of those two behaviors, the WP-CLI total can be lower than the core autoload set measured by the SQL query or Site Health.

That makes the SQL query the better reference when you need a WordPress 6.6+ total. The WP-CLI command is still useful for a fast inventory and for sharing results.

You can paste that exact list output into the free autoloaded options analyser. It calculates the total, surfaces the largest rows, and groups option-name prefixes so you can see which families of settings deserve attention first.

How to find which plugin owns a large option

Do not change a row just because its name is unfamiliar. First identify the code that creates and reads it.

Start with the option name

Prefixes often point to a plugin, theme, or internal module. An option named acme_plugin_settings is easier to trace than a generic name such as settings.

Treat the prefix as a clue, not proof. Plugins can rename products, share libraries, inherit old prefixes, or keep options after deactivation.

Search the code that reads and writes it

Search active plugins, must-use plugins, themes, and custom code for the exact option name. Look for calls such as get_option(), add_option(), update_option(), and register_setting() around that name.

If the full name is generated dynamically, search for a stable prefix. Also inspect inactive plugin code when the option may be left from an older installation.

The key question is usage scope. If code reads the option across front-end requests, REST requests, cron work, and admin screens, autoload may be justified. If the value is only used on one settings screen or one maintenance task, autoload deserves closer review.

Check whether the row is a transient

Without a persistent object cache, the Transients API stores transient data in the database, normally in wp_options. Names commonly begin with _transient_ or _site_transient_.

Current WordPress behavior matters here. A transient created without an expiration is autoloaded. A transient created with an expiration is not autoloaded by default.

With a persistent object cache, WordPress can store transient values in that cache instead of wp_options. If you are reviewing a site without one, the Redis object cache guide explains where persistent object caching fits into WordPress performance.

Do not delete a transient or option simply because it is large. Confirm which code owns it and whether deletion is part of that component's supported lifecycle.

How to change autoload safely

Changing the autoload flag is safer than deleting an attributed option because the stored value remains available through normal option reads. It can still affect application behavior, so make the change like any other production database change.

Use this sequence:

1. Back up the database before changing option metadata.
2. Reproduce the site on staging with the same plugins, theme, and relevant configuration.
3. Attribute the option to the code that owns it.
4. Confirm that the option is not needed across most requests.
5. Change one option at a time, then test the paths that use it.
6. Re-run the SQL measurement and confirm the expected row moved out of the autoload set.

Never delete an option you cannot attribute. A stale-looking row can still be read by code that is not obvious from the option name.

Use the WordPress API in PHP

WordPress introduced wp_set_option_autoload() in 6.4 (opens in a new tab). It changes the autoload value without changing the option value and handles the related option caches.

Pass a boolean in current code:

<?php
wp_set_option_autoload( 'acme_plugin_settings', false );

Use false only after confirming the option does not need to be loaded with the common alloptions set. If the plugin later calls get_option( 'acme_plugin_settings' ), WordPress can still fetch the value separately.

For code that creates or updates its own options, pass an explicit boolean when you know the intended behavior. Do not rely on a cleanup script to correct a plugin that keeps writing the wrong autoload choice.

Use WP-CLI for a single option

Current WP-CLI includes wp option set-autoload (opens in a new tab). To stop autoloading one attributed option:

wp option set-autoload acme_plugin_settings off

The command accepts on, off, yes, and no. Use on and off for current WordPress-style values.

Do not use a raw UPDATE wp_options SET autoload=... statement in a cleanup script. Prefer the core PHP API, or the WP-CLI command when you are changing an attributed option interactively.

After the change, test the feature that owns the option, normal front-end requests, relevant admin screens, scheduled tasks that depend on it, and any request path where the option is read.

What to do next

If autoload is only one part of a slow back end, continue with the slow WordPress admin diagnosis guide. It helps separate option loading from slow queries, HTTP calls, cron work, and plugin-specific admin behavior.

If you have a large database, persistent cache concerns, or several interacting bottlenecks, the WordPress performance optimization service covers profiling and remediation at the application and database layers.