How to Check Autoloaded Options in WordPress Before Deleting Anything

A performance report flags autoloaded options, and the obvious temptation is to delete the largest rows in the database. That is a poor starting point: a large option may contain configuration an active plugin needs.

Start with a read-only inventory. Find which options are autoloaded, measure their stored size, and identify who owns them. Only then decide whether an option should be retained, loaded on demand, or removed.

What autoload actually means

WordPress stores many settings in its options table. Autoloaded options are included in a collection loaded together during normal WordPress execution, rather than waiting for each setting to be requested individually.

That can be useful for frequently needed settings. It becomes worth investigating when a substantial amount of data is loaded for functionality used on only a small subset of requests.

Modern WordPress uses more autoload values than the older yes and no pair. WordPress 6.6 introduced changes to these values and automatic decisions for large options. A query that checks only autoload = 'yes' can miss relevant rows. WordPress Core: changes to option autoloading

Inspect the largest entries without changing them

The following example requires WordPress 6.6 or later and WP-CLI. Run it from the WordPress installation directory. For multisite, select the intended site with WP-CLI’s --url argument.

wp eval '
global $wpdb;

$values = wp_autoload_values_to_autoload();
$placeholders = implode(", ", array_fill(0, count($values), "%s"));

$sql = $wpdb->prepare(
    "SELECT option_name, OCTET_LENGTH(option_value) AS bytes
     FROM {$wpdb->options}
     WHERE autoload IN ($placeholders)
     ORDER BY bytes DESC
     LIMIT 20",
    $values
);

foreach ($wpdb->get_results($sql) as $row) {
    printf("%10d  %s\n", (int) $row->bytes, $row->option_name);
}
'

This prints names and stored byte lengths, not the option contents. It uses the site’s actual table name and asks WordPress which autoload values count. The official helper returns the supported values and allows WordPress filters to adjust that list. wp_autoload_values_to_autoload()

The numbers measure stored data size. They are not a measurement of PHP memory usage or time saved by removing an option.

WP-CLI also provides wp option list, with output fields such as option names, autoload values, and sizes. Check its documented flags when building a repeatable inventory for your environment. WP-CLI option list reference

Identify the owner and purpose

For each large entry, answer three questions: which plugin or theme writes it, where it is read, and whether it is still needed.

An option prefix can suggest ownership, but confirm it in the relevant code or documentation. An inactive plugin’s settings may be deliberately retained for future use. A generated cache may also be recreated immediately after deletion.

Record the option name, current autoload value, size, owner, and proposed action. This turns a vague cleanup into a change you can explain and reverse.

Loading on demand is different from deleting

If an option is needed only occasionally, disabling autoload may be appropriate. On WordPress 6.6 and later, the dedicated API can change that behavior without deleting its value:

wp_set_option_autoload( 'your_verified_option_name', false );

Replace the example name only after checking the actual option. Use this as a controlled maintenance operation, not a snippet that runs on every request. The value remains available through the options API. wp_set_option_autoload()

Test on staging and take a database backup before changing production settings. Check the owning plugin’s screens and the frontend features that depend on it. A plugin may later rewrite the option, so also verify whether your change persists.

Measure the result where WordPress executes

Compare equivalent requests before and after the change. Include uncached frontend requests and relevant admin screens; a fully cached page can hide the database work you are investigating.

Keep the environment and test conditions consistent. If autoloaded data shrinks but response time does not improve, report that honestly. Another query, external request, or server limit may be the bigger bottleneck.

Autoload inspection belongs inside a wider diagnosis. My WordPress performance overview explains how caching, assets, plugins, and infrastructure fit into that work.