The WordPress warning about autoloaded options is a reason to inspect frequently loaded settings, not permission to delete the largest database rows. Identify which component owns each large option and whether it needs to load on ordinary requests. A smaller count alone does not prove the site is faster.
Record the warning and the slow task
Capture the Site Health message, WordPress version and observed slow operation. Compare the public page, logged-in dashboard and background workload. An options warning can coexist with a slow external API or overloaded database that is the more important bottleneck.
Keep the slow admin diagnosis available if only a particular screen is affected. Do not use a frontend speed score as the only measure of an admin repair.
List names and sizes, not secret values
On an authorized environment with WP-CLI, start with its option-list documentation. Confirm the installed command supports the options you intend to use:
wp help option list
wp option list --fields=option_name,autoload,size_bytes --format=table
The second command lists option metadata rather than option values. It may be lengthy on a large installation. Keep the result private because even names can reveal integrations or operational details. Avoid dumping option_value into a public ticket.
Do not rely on a hand-written SQL filter that counts only autoload='yes'. WordPress's autoload changes explain why modern behavior has more states. An older database query and current Site Health can therefore disagree without either database corruption or a new attack.
Backup: Restoration available. Owner: Setting still works. Request: Comparable timing. Growth: Option does not refill blindly. Explanatory checklist, not a customer test result.
Assign an owner before changing anything
For each large candidate, record its option name, approximate size, active plugin or theme owner and whether it grows repeatedly. A log or cached response has different cleanup semantics from a serialized business configuration.
Check the owner's documentation or support channel for a supported cleanup mechanism. A disabled plugin can leave settings that are still needed for a future restoration. A misleading prefix is not enough evidence to delete an option.
Test one supported change
Take a restorable database backup and test on staging. Where the owner approves disabling autoload for a rarely used option, use the supported WordPress API or tool for the installed version rather than editing serialized values directly.
Changing autoload preserves a value but changes when it is retrieved; deleting the option removes the value entirely. Neither action should be applied indiscriminately to every large row.
After the change, test the owner's settings screen and business workflow as well as the original slow request. Compare like-for-like timings and check whether the option is recreated or grows again.
An option that returns to its old size needs a producer-level diagnosis, not a daily deletion task. HandL WP can investigate options-related overhead with the option owner, size trend and measured request behavior.
References reviewed October 13, 2026. Examples are explanatory, not customer test results.