Autoloaded options

Autoloaded Options – Autoloaded Options

You have a problem in your WordPress installation with the following message?

Autoloaded options can affect performance. Autoloaded options are configuration settings for plugins and themes that are automatically loaded every time a page is loaded in WordPress. If there are too many autoloaded options, they can slow down your site. Your site has 1900 autoloaded options (size: 1500 kB) in the options table, which can cause your site to be slow. You can review the options that are automatically loaded by your database and remove any options that are no longer needed by your site.

Here is the procedure to capture and fix the problem:

To optimize the autoloaded options in WordPress, it’s crucial to regularly check and clean the wp_options table so that it doesn’t load too many or too large option values on each page request. Too many autoloaded options cause performance problems because they are loaded into memory every time a page is loaded, regardless of whether they are actually needed.

What are autoloaded options?

• In table wp_options, there is an autoload (“yes” or “no”) field that regulates whether an option is loaded into memory every time a page is loaded.
• Settings for plugins and themes, but also temporary caches such as transients, often end up with “yes” in the autoload.
• If the amount of this data (>1MB, critical at >3-5MB) is too large, this has a negative effect on performance.

Optimisation measures

• With SQL queries in phpMyAdmin or via plugin (e.g. Autoload Checker, AAA Option Optimizer), the size and number of autoloaded options can be analyzed and specifically restricted.
• Delete outdated or unnecessary plugin/theme entries from wp_options and set the autoload attribute to “no” for rarely used options (e.g. via SQL: UPDATE wp_options SET autoload = 'no' WHERE option_name = 'NAME';).
• Regularly clean up expired transients with SQL:
  DELETE FROM wp_options WHERE autoload = 'yes' AND option_name LIKE '%transient%';.

Best Practices for Developers

• Only options that are needed on each page should be truly autoloaded (e.g. global theme settings).
• It is better to store large arrays or rarely needed configurations with autoload = “no” or in your own tables.
• When deactivating plugins, hooks can be used to set autoload to “no” instead of deleting options completely.

Note: Since WordPress 6.6, there are other values besides “yes/no” (“on”, “auto”, “auto-on”), and not all tools recognize them correctly.

Useful tools and plugins

• Autoload Checker (up-to-date and compatible)
• AAA Option Optimizer (shows usage on pages)
• Advanced Database Cleaner (plugin-based option control)

Targeted optimization reduces server load, reduces memory usage, and noticeably improves page load times.

How do I check the total size of the autoload options in the database

The easiest way to determine the total size of the autoload options in the WordPress database is to use an SQL query. This returns the sum (in bytes) of all the autoloaded options. The standard SQL query for this is:

sql:
SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes
FROM wp_options
WHERE autoload = 'yes';

The result (“autoload_size_bytes”) is the size in bytes. For better readability, this value can be divided by 1024 to get kilobytes (KB). If a different table prefix is used, “wp_options” must be adjusted accordingly.

For several new WP values (from WP 6.6, e.g. “yes”, “on”, “auto”, “auto-on”):

sql:
SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Alternatively, plugins such as “Autoload Checker” offer a convenient graphical overview of the total size and warnings if limit values are exceeded.

An autoload total size of less than 1MB is considered uncritical, from 2-3MB and more should be optimized urgently. The total size of all autoload options in the database can be determined directly with a simple SQL query. This outputs the sum of the byte lengths of all automatically loaded entries in the wp_options table:

sql:
SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes
FROM wp_options
WHERE autoload='yes';

The result value is in bytes, for example, 1048576 bytes = 1 MB. If WordPress 6.6 or newer is used and modern autoload values such as “on”, “auto”, “auto-on” are also used, you should adjust the query as follows:

sql:
SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

With this query, you can quickly find out whether there is a need for optimization – a size of less than 1 MB is usually considered non-critical, from 2-3 MB you should clean up.

Best practice for which options autoload=yes should have

Only options that are actually needed on every page load should receive the autoload=yes attribute. The best practice is to set this flag specifically only for globally relevant settings and configurations – this ensures optimal performance and avoids unnecessary memory load.

What options should autoload=yes have?

• Global theme settings such as site title, language, default color, logo – as they are needed on every page.
• Central plugin configurations that are required on all pages and for each request, e.g. general settings of a caching plugin or a security plugin.
• Settings for functions that WordPress reads directly during bootstrapping, e.g. the widget configuration for globally integrated sidebars.
• Small, commonly used option values (strings or arrays in KB size) that need to be loaded quickly.

Options that should NOT be autoloaded

• Settings that are only needed in the backend, in certain plugins, or rarely (e.g. plugin settings that are only relevant in the admin dashboard).
• Large arrays or data structures, e.g. statistical data, import caches, long-term transients, etc.—they should be kept autoload=no or better stored in their own DB tables.
• Temporary values, such as transients and entries, that are relevant only to specific URLs.

Developer Tips

• When creating an option in the code add_option() or update_option(), always set the autoload flag specifically. Example: add_option('my_plugin_cached_settings', $data, '', 'no'); for rarely used data.
• As of WordPress 6.6, autoload can also be set to “auto” so that WordPress itself heuristically decides what to autoload. For critical options, however, continue to use “yes” or “no” in a targeted manner.

In case of uncertainty, less is more! In practice, there should usually be <20–40 option values with autoload=yes, and the total size should not exceed 1MB if possible. The autoload=yes attribute should only be assigned to options that are indispensable for every page view – for example, global theme settings or central configurations of active plugins. Options that are only needed in the backend or contain large amounts of data should definitely use autoload=no.

When autoload=yes makes sense

• Global website settings, such as site title, primary language, or logo.
• Essential plugin or theme configurations that the frontend needs on each page (e.g. cache settings or security configs).
• Small option values that are called frequently (max KB size).
• Widget coordinates for globally integrated sidebars.

When autoload=no makes sense

• Options that are only relevant in the WP admin or for specific URLs (e.g. plugin settings for backend pages).
• Large arrays/objects (e.g. statistical data, import lists) that inflate the payload.
• Short-term values such as transients or specific plugin-related data.

Developer Notes

• Always set autoload specifically: add_option()/update_option() with parameter.
• For new projects from WP 6.6 onwards, autoload=”auto” can be useful; but explicitly use “yes” or “no” for critical data.

Only the most important (<40) and as small as possible options should be autoloaded, ideally the total size should remain under 1MB.

SQL query to list large autoload options by size

The following SQL query lists the largest autoloaded options from the wp_options table (default prefix) and sorts them by their amount of data in descending order. This makes it easy to identify the biggest memory hogs and, if necessary, optimize or remove them in a targeted manner:

sql:
SELECT 
  option_name,
  LENGTH(option_value) AS option_size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size_bytes DESC
LIMIT 50;

The result shows the names and byte sizes of the top 50 options with autoload=yes. If a different table prefix is used, wp_options must be adjusted accordingly.

Alternatively for several autoload variants (from WP 6.6, e.g. ‘yes’, ‘on’, ‘auto’, ‘auto-on’):

sql:
SELECT 
  option_name,
  LENGTH(option_value) AS option_size_bytes,
  autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY option_size_bytes DESC
LIMIT 50;

This gives you the largest autoloaded options including newer WP values.

Regular monitoring of these values helps to identify performance problems at an early stage and to remedy them in a targeted manner.

How to safely remove orphaned options from deleted plugins

Step-by-step instructions

Backup of the database

Before making any changes, be sure to create a complete database backup, e.g. via phpMyAdmin or plugin.

Identifying Orphaned Options

Search for option names that contain the prefix or suffix of the deleted plugin, e.g. with:

sql:
SELECT option_name FROM wp_options WHERE option_name LIKE '%beispielplugin%';

Plugin-specific patterns such as _pluginname_setting often help here.

Disable orphaned options

Before deleting, the autoload attribute can be set to “no”:

sql:
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'EINTRAG';

See if the site continues to work as expected to avoid unexpected side effects.

Deleting orphaned options

If there are no errors after a trial period, the options can be safely deleted:

sql:
DELETE FROM wp_options WHERE option_name = 'EINTRAG';

Alternatively, delete according to several patterns:

sql:
DELETE FROM wp_options WHERE option_name LIKE '%pluginname%';

For transients:

sql:
DELETE FROM wp_options WHERE option_name LIKE ('%transient%');

Automated tools and plugins

Use plugins such as “Advanced Database Cleaner” or “WP-Optimize”, which often automatically detect orphaned options and provide them for confirmation via a UI.

WP-CLI commands simplify the deletion process for developers, e.g. wp option delete option_name.

Important notes

• Never remove options that can be assigned insecurely – always research which plugin/theme they could belong to.
• In the case of unusual prefixes, it helps to research historical plugin names or take a look at older plugin files.
• Avoid at all costs: deleting or changing critical WordPress core options!

Regular cleanup reduces database size and the risk of load time issues. Plugins such as Advanced Database Cleaner or WP-Optimize support targeted cleanup and automation of control.