WordPress autoload options audit: how to find and reduce unnecessary load

What autoload is and why it affects performance

When WordPress loads, it builds a collection of options marked for automatic loading. These values are then available to plugin and theme code without a separate database query. This is convenient for small settings that are needed on almost every request.

The problem arises when large serialized arrays are included in autoload data: caches, product lists, logs, scan results, page builder data, or outdated settings left behind after a plugin is removed. The larger the total volume of these options, the more memory PHP may use on every request.

It is important to assess not only the single largest record but also the total volume of autoload data. A large number of medium-sized options can also create a problem.

• Autoload does not mean that an option is loaded only on the home page — it may be read on the frontend, in the administration area, and during AJAX requests.
• The size in the database does not equal the exact amount of memory used after PHP arrays are unserialized: in memory, the value often takes up more space.
• A slow database is not always the root cause: excessive autoload data can increase load at the PHP level.

How to find the largest autoload options with SQL

Before checking, identify the actual table prefix used in the database. On many sites it is not wp_ but another value, so replace wp_options in the queries with your own table name.

Run the query in phpMyAdmin, Adminer, or another MySQL management tool. It will show the largest options that WordPress generally treats as being loaded automatically.

• Do not run data-modifying queries until you have a current database backup.
• Check the result on staging if the site has active traffic or a complex configuration.
• Pay attention to option_name, the size, and whether the option belongs to a specific plugin or theme.

SELECT option_name,
       ROUND(LENGTH(option_value) / 1024, 1) AS kb,
       autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

How to estimate the total volume

A single large record is not always critical if the total autoload volume is small. For an overall estimate, use an aggregate query. It will show the approximate size of the values in kilobytes.

SELECT COUNT(*) AS autoload_options,
       ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS total_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on');

Checking autoload values in a specific database

Different WordPress versions and compatible tools may use different values in the autoload field. Modern versions may use automatic values such as auto-on and auto-off, so before making changes it is useful to see which values are actually present in your database.

SELECT autoload, COUNT(*) AS options_count
FROM wp_options
GROUP BY autoload
ORDER BY options_count DESC;

How to identify which plugin created a large option

The option name often contains a plugin or theme prefix, such as a brand abbreviation, module name, or developer identifier. However, this is not a universal rule. A plugin may store some data under a neutral name, and records may remain in the database after the extension has been removed.

Compare option_name with the plugin documentation, its source code, or a search through the extension files. In the code, look for add_option, update_option, and the option name itself. Also check whether the relevant plugin is currently installed and whether the site uses its features.

Do not delete an option simply because its name is unfamiliar. It may contain critical settings, integration keys, shipping rules, theme configuration, or data required to restore normal operation.

• Create a database backup before any cleanup.
• Record the current option value or export the corresponding table row.
• Check the site after disabling the plugin on staging: if the option is no longer used, this is stronger evidence that it can be cleaned up.
• Check separately for leftovers after fully removing plugins, but do not assume that every remaining record is safe to delete.

Safe ways to reduce autoload data

The best solution is to eliminate the cause rather than simply changing a database flag. Update the problematic plugin or theme: the developer may already have fixed excessive data storage. If the option is related to an unnecessary feature, disable that feature in the settings.

If a value is not needed on every request, it can be switched to a mode that does not load automatically. Before doing this, make sure the plugin retrieves the option correctly when needed. Some extensions incorrectly expect their configuration to always be present in the global autoload set.

Changes can be made through a WordPress management tool or directly in SQL. The exact method depends on the WP-CLI version, the WordPress version, and the values supported by your installation. If you use SQL, change only a precisely identified option_name.

• Do not change autoload for all options in bulk without analyzing dependencies.
• Do not set a value that is not available in your version or site configuration without checking compatibility.
• For a single option, use a targeted change and immediately check the frontend, administration area, forms, payments, and integrations.
• Deleting an option is a last resort. It is different from disabling autoload and may result in lost settings.

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'example_option_name';

When autoload should not be changed

Do not switch an option to a non-autoload mode if it is genuinely used on almost every request or if the plugin documentation explicitly requires automatic loading. In that case, the benefit may be zero, while the number of separate database queries may increase.

Also be careful with theme options, WooCommerce, caching solutions, authentication systems, and integrations. For these components, the consequences of an error may not become visible immediately.

How to check the result after making changes

After changing autoload, clear the object cache if one is in use and check the site in a new PHP session. Some data may temporarily remain in a memory cache or Redis, so the result is not always visible immediately.

Go through key scenarios: open several pages, log in to the administration area, and check search, forms, the cart, checkout, payments, and integrations. Review the PHP error log and the WordPress error log.

Repeat the SQL audit and compare the total volume and the list of the largest records. Do not assess only one metric: response time, PHP memory usage, errors, and feature stability also matter.

• Check pages for both logged-in and logged-out users.
• Check whether errors appear after an automatic update or cache purge.
• Record the changes so you can quickly revert a specific option if necessary.
• If the result is negative, restore the previous autoload value and repeat the test with advice from the plugin developer.

Common mistakes when auditing wp_options

The most common mistake is deleting the largest records without understanding their purpose. Size alone does not prove that an option is unnecessary. Another mistake is checking only one record without calculating the total autoload volume.

You should also not assume that changing autoload will automatically solve every performance issue. The cause may be slow plugin queries, a missing object cache, poorly optimized external API requests, or excessive PHP load.

Regular audits make sense after installing large plugins, migrating a site, changing the theme, removing extensions, or seeing a sharp increase in memory usage. Ideally, perform the audit on staging and apply only tested changes to production, with a backup available.

• Do not confuse autoload cleanup with deleting all unused options.
• Do not use the same SQL queries for sites with different table prefixes.
• Do not evaluate the effect based on only one speed test.
• Do not ignore errors after making a change: even a small option may be important to business logic.