Autoload in wp_options: the hidden brake on your WordPress

When a WordPress site runs slow, almost everyone looks at images or plugins. But there is a silent culprit that almost nobody checks: the wp_options table and its options with autoload. If your site spends extra time on every request before responding, the problem may be here, even before caching comes into play.

What autoload is and why it matters

WordPress stores site, plugin, and theme settings in the wp_options table. Each row has an autoload column. Rows marked as yes are loaded on every PHP request, whether they are going to be used or not, in a single query at startup.

This is convenient for small settings (site name, URL, permalinks). The problem appears when plugins you already uninstalled, or that store large amounts of data (logs, scan results, poorly managed transients, huge serialized configurations), leave megabytes marked as autoload.

How it manifests

• A high TTFB on pages that are not cached: the admin panel, the cart, the checkout, pages with logged-in users.
• High PHP memory consumption on simple requests.
• Slower-than-normal cache regenerations, because each one starts WordPress completely.

How to measure your case

There is no need to guess. With access to the database (phpMyAdmin, Adminer, or WP-CLI) you can see how much the autoload weighs:

• Sum the size of the rows with autoload = 'yes' using SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; (adjust the table prefix if it is not wp_).
• List the ten largest options with SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY bytes DESC LIMIT 10;
• On the site, the WordPress Site Health plugin can also warn when autoload options are excessive in recent versions of the core.

As a practical rule, if the total is counted in several megabytes, it is worth investigating. If it is a few hundred kilobytes, your bottleneck is probably somewhere else.

How to clean it up without breaking anything

1. Make a backup of the database before touching anything.
2. Identify the owner of each large option: the name prefix usually gives the plugin away.
3. If the plugin no longer exists, delete its orphaned options.
4. If the plugin is still active and the option is rarely read, change it to autoload = 'no' instead of deleting it; WordPress will read it on demand.
5. Remove expired transients that have accumulated.
6. Measure the response time again and compare it with the starting point.

What not to do

• Do not delete options whose origin you do not know just because they are large.
• Do not change core options to no (siteurl, active_plugins, etc.).
• Do not do it in production without testing first in a staging environment if the site is a store.

And caching, doesn't it solve it?

Partly. A page cache that serves static HTML avoids running PHP and querying the database for anonymous visitors, so that problem disappears for most traffic. You can see the mechanism in how cache.lat works: the page is generated once and then delivered as a file.

But there are two moments when the database still matters: when a page is regenerated (after publishing or purging) and in all the dynamic content that cannot be cached (administration, cart, user accounts). A clean database makes both faster. If you want to understand what is served statically and what is not, check the technical data and the documentation.

Quick checklist

• Measure the total weight of the autoload.
• Review the ten largest options.
• Remove leftovers from uninstalled plugins.
• Change to no what is not needed on every request.
• Clean expired transients.
• Compare TTFB before and after, both with and without caching.

Doing this maintenance once every few months costs little and prevents the database from becoming an invisible burden. If you have questions about how it fits with your configuration, you can contact the TuNegocioEnLinea.net team.