Before you start — is this your problem?
- Your site used to feel fast and now takes 3–5 seconds (or more) to load.
- It feels slow across most pages, not just one specific section.
- You’ve upgraded your hosting or PHP version and performance barely improved.
If all three sound familiar, keep reading. If not, it’s worth checking other common causes first, such as large images, caching, JavaScript, external APIs, or your CDN configuration.
One common cause of slow WordPress sites—especially older ones—is excessive autoloaded data left behind by plugins. Fortunately, it’s something you can usually identify and improve in an afternoon.
A slow WordPress site is rarely a hosting problem. It’s almost always a database carrying years of leftover plugin data on every single page load — and that’s fixable in an afternoon without touching your hosting plan.
The real culprit: autoloaded options
Many plugins store configuration data in the wp_options table. Some of these options are saved with autoload = 'yes', which tells WordPress to load them into memory on every request, regardless of whether the current page actually needs them.
On a fresh WordPress installation, the total autoloaded data is usually quite small. As sites grow, install more plugins, and accumulate years of updates, it’s common for this to reach several megabytes.
That doesn’t automatically mean your site will be slow—but it does mean WordPress has more data to load on every page request, making it worth investigating.
Step 1: Measure it
Install Query Monitor (free) and check its Autoloaded Options panel.
Or, if you prefer SQL, run:
SELECT option_name,
ROUND(LENGTH(option_value)/1024,2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes','on')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;As a general guideline:
- Under 1 MB is usually healthy.
- Between 1–3 MB is worth reviewing.
- Above 5 MB often deserves investigation, especially if you’re not using persistent object caching (Redis or Memcached).
Remember that these aren’t hard limits. WooCommerce stores, multisite installations, and larger sites naturally tend to have more autoloaded data.
Step 2: Identify what’s safe and what’s junk
Many option names clearly indicate which plugin created them—for example:
elementor_*wpforms_*aioseo_*
If the plugin is still active, leave those options alone unless you know exactly what you’re doing.
If the plugin was removed months or years ago and you don’t plan to reinstall it, those leftover options are often safe candidates for cleanup.
Some common examples:
rewrite_rules— often large, especially on WooCommerce sites. Leave it alone; WordPress regenerates it when needed._site_transient_*and_transient_*— cached data. Generally safe to delete because WordPress recreates these automatically.cron— stores scheduled tasks. If it’s unusually large, it’s usually better to remove unused scheduled events rather than deleting the entire option.theme_mods_*,active_plugins, and variouswidget_*options are core WordPress data and shouldn’t be removed without understanding their purpose.
Step 3: Clean it up
Before making any changes, create a database backup.
Instead of deleting options immediately, inspect them first:
SELECT option_name,
autoload,
ROUND(LENGTH(option_value)/1024,2) AS size_kb
FROM wp_options
WHERE option_name='your_option_name';If you’ve confirmed the option belongs to a plugin that has been permanently removed, you can delete it:
DELETE FROM wp_options
WHERE option_name='your_option_name';If SQL isn’t your thing, plugins like Advanced Database Cleaner or WP-Optimize provide a graphical interface for finding orphaned options.
After cleaning up, rerun the query from Step 1 to see how much you’ve reduced the autoloaded data.
Step 4: Make it a habit
Database bloat accumulates over time from plugin installs, theme changes, and abandoned experiments.
A simple maintenance routine can prevent it from growing again:
- Delete expired transients regularly (WP-Optimize can automate this).
- Review your autoloaded options every month or two.
- Completely remove plugins you no longer use instead of simply deactivating them.
- Periodically review old themes, widgets, and scheduled cron jobs.
A quick note about object caching
If your site uses Redis, Memcached, or another persistent object cache, large autoloaded data may have less impact because WordPress doesn’t need to rebuild those objects on every request.
Even so, removing unnecessary options keeps your database cleaner, reduces memory usage, and can improve cache efficiency.
The bottom line
Autoloaded options aren’t the cause of every slow WordPress site—but they are one of the easiest performance issues to measure and fix.
An hour with Query Monitor and a careful cleanup can tell you exactly how much unnecessary data WordPress is loading on every request. In many cases, reducing that overhead results in a faster, leaner site without changing your hosting plan.
Want us to take a look at yours?
If you’d rather not dig through wp_options yourself, send us your site and we’ll perform a free autoload audit.
We’ll identify what’s normal, what’s unnecessary, and what can be safely cleaned up—no obligation required.