WordPress Autoloaded Options: Find and Fix wp_options Bloat

If your WordPress site seems sluggish despite having taken common measures like installing a caching plugin or compressing images, you may need to dig deeper. A hidden factor could be the wp_options table within your database.

To put it simply, when WordPress processes a request, it loads all autoloaded options into memory in one go, utilising the persistent object cache when it’s available and querying wp_options if the data isn’t cached. While this is standard practice, the issue arises when options from plugins you’ve long since uninstalled remain in your database, still marked for autoloading. This means WordPress continues to burden memory with these outdated entries.

This guide will explain what autoloaded options are, how to assess them using two safe, read-only SQL queries, which options you can safely modify, which ones to avoid, and the potential performance improvements you might gain. Let’s delve in.

What Are Autoloaded Options?

The wp_options table acts as a settings repository for WordPress. Each entry consists of a name (option_name), a value (option_value), and an autoload flag. When the flag is set, WordPress loads that entry into memory at the start of each request, retrieving all autoloaded rows in a single query. This approach was designed for speed, allowing WordPress to retrieve site title, active plugins, timezone, and more without running separate queries for each piece of data. According to the official developer notes on the Options API changes, this method, called “autoloading,” inadvertently resulted in many options being loaded unnecessarily on every page.

With the introduction of WordPress 6.6, the autoload column can now hold more than just the traditional yes and no flags. New values such as on, off, auto, auto-on, and auto-off enable WordPress to determine dynamically whether an option warrants preloading. The older yes and no values still function as on and off. Additionally, options exceeding 150,000 bytes are no longer autoloaded by default, and the Site Health tool (Tools → Site Health) will flag a critical warning stating, “Autoloaded options could affect performance,” if your autoloaded total exceeds 800 KB.

So, where does the extra bloat originate? Primarily from leftover data after uninstalling plugins. When a plugin is removed, its settings entries often remain in wp_options with autoload still enabled. Some plugins may also store data that isn’t intended for universal loading: debug logs, cached API responses, or large serialized arrays. Over time, this accumulation can transform small data sizes into significant megabytes.

First and Foremost: Backup Your Database

WARNING: Always perform a complete backup of your database before making any changes in wp_options. Incorrect modifications can lead to a white screen on your site or click you out of wp-admin. Many hosting providers offer one-click backups, and you can use phpMyAdmin’s Export tab as an alternative. If you have a staging site, it’s wise to practice there first.

To clarify the risks: the SELECT queries below are safe to execute, as they only read data. However, the UPDATE and DELETE statements later in the guide are where your backup becomes essential. Do not skip this step.

Step 1: Assess How Much Data WordPress Autoloads

Access your hosting control panel and open phpMyAdmin (if you’re using cPanel or Plesk, you should find it on the main dashboard; managed hosts have similar database tools). Select your site’s database from the left sidebar, then click the SQL tab and paste in the following query:

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

Click Go, and you’ll receive one figure: the total size of all autoloaded content on each page load, measured in kilobytes. The IN clause encompasses all four values recognised by current WordPress as autoloaded (this list mirrors the output of the core function wp_autoload_values_to_autoload(), per the Options API reference). If you’re operating on a version prior to WordPress 6.6, you can use a simpler WHERE autoload = 'yes'.

One caution: if your wp-config.php has a custom $table_prefix, ensure you replace wp_options with your actual table name, such as abc123_options.

An example from a nearly fresh install of WordPress 7.0.2 yielded a result of 69 KB spread across 133 autoloaded entries:

What’s the assessment benchmark? If your total nears or exceeds 800 KB, WordPress flags it as a critical issue within Site Health. A well-optimized site typically registers in the low hundreds of kilobytes or even lower, like the test example. Older sites with years of plugin changes tend to accumulate totals that have grown into megabytes.

Not keen on SQL? You can install the free Performance Lab plugin, developed by the official WordPress Performance Team. This plugin enhances the Site Health check, displaying a table of your autoloaded options, allowing you to review and disable unneeded ones directly from wp-admin, eliminating the need for queries.

Step 2: Identify the Largest Offenders

If your total size appears significant, the next query identifies which options occupy the most space. In the same SQL tab, conduct the following:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 10;

Interpreting the results is simpler than it seems, as option names are typically prefixed by their plugin origin. In the screenshot provided, rewrite_rules ranks highest at about 33 KB, which is integral to WordPress (linking pretty URLs to content) and should remain unchanged. The _transient_ rows represent temporary cached data, while trp_ entries refer to a translation plugin you may have installed.

Look for:

• Prefixes from plugins you’ve removed a long time ago. If the plugin is gone, its entries are purely excess baggage and should be prioritised for removal.
• Large values from active plugins that should not load universally. For instance, settings from an import tool or logs from a backup plugin shouldn’t be loaded on your homepage.
• An accumulation of outdated transients. Entries beginning with _transient_ are designed to expire, but some can hang on longer than expected.

Step 3: Modify or Remove the Unwanted Ones

Two scenarios necessitate two different actions:

• If the option belongs to a currently used plugin but is only necessary in admin areas (for instance, importers, backup settings, or analytics), switch its autoload off. This retention keeps the data intact while stopping WordPress from preloading it. The worst-case scenario is that this option adds a single extra query during the screens that need it. This change is completely reversible.
• If the option relates to a deleted plugin. In this case, delete the entry entirely. First, confirm on the Plugins screen that the plugin is truly absent, and check for a matching prefix.

To toggle an option, you would use a command like this:

UPDATE wp_options SET autoload = '' WHERE option_name="some_plugin_settings";

CAUTION: Make adjustments one row at a time and always match the precise option_name. Avoid the use of wildcards like LIKE in an UPDATE or DELETE command on this table; an errant pattern could modify numerous rows. Reload your website following each alteration. To revert a flip, simply run the same command substituting 'yes' for ''.

To eliminate an entry from a definitely uninstalled plugin, use:

DELETE FROM wp_options WHERE option_name="long_gone_plugin_settings";

Regarding transients, individually cleaning them can be laborious. Deleting entries with the _transient_ prefix is generally safe as WordPress regenerates them, but a cleanup plugin like WP-Optimize provides a one-click solution to remove expired ones, making it much more efficient than sifting through hundreds of entries.

Options You Should Never Modify

Certain entries within wp_options are essential. Altering or removing them won’t enhance performance; instead, it could damage your site. Avoid these:

• siteurl and home: these define your site’s URL. Changes here will lead every page to break.
• active_plugins: this outlines your running plugins. Corrupting it could deactivate everything at once, often accompanied by a white screen.
• wp_user_roles: this contains your permission settings. Tampering with it could lock you out of wp-admin.
• cron, rewrite_rules, template, stylesheet: these handle scheduling, URL routing, and your active theme. They are all crucial and required on every page.
• Any option that you cannot definitively associate with a particular plugin, theme, or core function. Unknown names? Leave them alone.

One additional guideline: never manually edit a serialized option_value. These values may appear as a:3:{s:4:"name";...}, with each digit reflecting a character count. Altering any character without adjusting the counts will corrupt the entire value. If you need to modify a value, use the settings screen of the associated plugin.

As a general principle, when uncertain, it’s better to disable autoload than to delete. And if you’re still unsure, it’s best to leave the entry untouched. A few extra kilobytes won’t harm anyone, but a missing core option might cause significant issues.

What Speed Enhancements Can You Anticipate?

The straightforward response: it varies based on how substantial the bloat is. If your autoloaded total rests in the low hundreds of kilobytes, trimming it will yield negligible time savings that are hard to measure. However, on older, plugin-heavy sites where megabytes of junk are autoloaded, the benefits are measurable, affecting every request that initiates WordPress: both the frontend, wp-admin, and AJAX interactions. Specifically, backend screens cannot be optimised solely through page caching, so a leaner autoload pile significantly accelerates the whole dashboard.

It’s equally important to clarify what this process won’t resolve. Cleaning autoloaded options won’t affect render-blocking JavaScript, bulky images, suboptimal fonts, or sluggish hosting. If your primary bottleneck resides on the front end (which is often the case), begin with these five essential tips to enhance WordPress speed, then return to address database tidiness.

Think of this maintenance as decluttering a junk drawer: rewarding, sometimes surprising, and advisable after a significant plugin spring cleaning. Just remember not to overlook an issue that was never in that drawer!

Final Thoughts

Autoloaded options represent an often unnoticed burden on each page load, but now you understand how to review yours:

• Backup your database prior to making any modifications.
• Assess your autoload total using a simple SELECT query (or via the Performance Lab plugin).
• Identify the largest entries and categorise them by prefix.
• Disable autoload for admin-only options and remove rows linked to uninstalled plugins.
• Steer clear of core options such as siteurl, active_plugins, or wp_user_roles.

Have you evaluated your autoloaded options yet? What figures did you uncover, and were there any surprises in your top ten? Let us knw in the comments below!

FREE GUIDE

4 Essential Steps to Speed Up Your WordPress Website

Follow our straightforward steps in this four-part mini-series and cut your loading times by 50-80%.

Yay! You’ve reached the end of the article!