If you run a WordPress site for a while, it’ll become cluttered. You’ve installed and uninstalled dozens of plugins over the course of your site being alive, and many of those plugins have left their footprint (their options) in your database. I’ve come up with a solution for this, which is the first step of something that I think can be even nicer.
Why is this a problem?
This wouldn’t be so bad if WordPress didn’t load all the options that are set to “autoload=yes” into its memory in one big load action. Since stray options stay behind in the database when you uninstall a plugin, those options are still loaded into the memory on every pageview. Every. Single. Time.
How can we solve this?
To solve this, we have to follow a few steps:
- Determine how bad the problem is by seeing how many autoloaded options we have and how much memory is being used by those options right now.
- For a while, keep track of all the autoloaded options and whether they are being used. Simply put: every time an autoloaded option is used during page load, we store it. Then we compare the list of options that have been used with those that have been autoloaded. The difference between the two are all the options that are autoloaded but never used.
- Now we have a list that we can go through and decide to either delete the option entirely or, if you’re unsure, simply remove the autoload=yes from it. If you do the latter, everything keeps on working; the option just isn’t loaded on every page load.
You’re now asking yourself: that sounds quite simple, but… How do I do that?? Well. I’ve built a plugin for it 🙂
Meet AAA Option Optimizer
This plugin is called AAA Option Optimizer. What’s with the funny name? Well, WordPress loads plugins alphabetically. To best measure which options are being loaded, it’s best for the plugin to be loaded early. So… I called it AAA Option Optimizer!
When you install the plugin, it measures the current standings immediately and stores them. No need for you to worry about that. Then you should go and click around your site. Be sure to hit every page, both in the front end and in the admin. You could use something like Screaming Frog on the front end.
Then you go to the plugin’s page. It’s under Tools. It’ll look something like this:
On this page, you remove the options that you no longer need, and you can optimize away. Be sure to make a backup before you do this, because you might of course break things. This is a power tool, don’t give it to people who don’t know what to do with it.
Future versions: auto optimization?
I actually think this could be turned into something that auto-optimizes. Removes autoload from options automatically when they’re never used, add autoload to options that get called a lot but aren’t auto-loaded.
I’d love to hear your thoughts!
Update 15th April 2024: the plugin made it to WordPress.org today!
I like this very very much.
I’d also love to share our list of items we force autoload = ‘no’ for all our hosting customers with you Joost. No need to load all this on *every* page load. Bloat, un-sustainable.
Also: actually removing options (per accident or not) is tricky, I am not sure I would like to have that delete button myself …
Interesting plugin, thank you.
I ran Screaming Frog (free version limited to 500 results) and WP Rocket preload cache service on a Woocommerce project and no additional options appeared. Is this to be expected?
Is the plugin in its current form suited for usage on production websites?
Nicely done. A potentially useful addition is trying to figure out and record which plugin an option was added from. I imagine that might involve parsing each plugin’s files for add_option() or update_option() instances, but maybe there’s a simpler way? If this makes sense, the next useful thing is to check if said plugin is still installed and active, or inactive or uninstalled alltogether. This would help decide if an option should no longer be autoloaded or is safe to delete.
Yes, well needed. In fact, I was in search of this tool for some time.
Insight: My role is responsible for our organization’s 35 websites with one other worker (newbie). I’m not a code developer, but rather an advanced WP’er with science and art mixed – responsible for both the creative and functional aspects of all sites. With so many sites and clients I rely on knowing the best plugins that work cohesively together with some customization using code snippets, html, css, etc. As tech changes, so does that chemistry. My relationships with plugin authors/vendors has been a crucial key to success. But when two or more plugins reek havoc, then the ecosystem becomes difficult to maneuver a solution. Such an event occurred with symptoms of 502/504 errors. The theme (Enfold) optimization settings, WP-optimize and other plugin settings caused an unescapable huge load on the server. Multiply that by 35 websites all using the same tools on a single server. As I set out to optimize (autoload settings and mini-fication) the server’s space and cpu climbed where re-creation of cache and logging nearly froze our entire web portfolio. Panic 🙂 but calm required to gain normality. I deleted WP Optimize and our host provider deleted cache logs simultaneously. Crash averted.
Perhaps like debug tool in Gravity Forms that allows to mimic plugin deactivation on a live site without affecting public view.
Unfortunately, the WordPress option system doesn’t “know” any of this.
After the first 2 pages I wouldn’t be surprised; and they might well be hit even while you were still playing in the admin.
Hello,
Thanks for the plugin.
I noticed that there are no “Remove Autoload” / “Delete Option” buttons on unused autoload options. Maybe you have removed them?
Also, on a Hostiger site, I get the following error when loading the Tools > Option Optimizer page.
Fatal error: Uncaught Error: strlen(): Argument #1 ($string) must be of type string, stdClass given in /home/z562613237/domains/disorder.com/public_html/wp-content/plugins/aaa-option-optimizer-
main/src/class-admin-page.php on line 84
Call stack:
strlen
wp-content/plugins/aaa-option-optimizer-main/src/class-admin-page.php:84
Emilia\OptionOptimizer \Admin_Page: :get_length(
wp-content/plugins/aaa-option-optimizer-main/src/class-admin-page.php:238
Emilia\OptionOptimizer \Admin_Page:: render_admin_page)
wp-includes/class-wp-hook.php:324
WP_Hook:: apply_filters)
wp-includes/class-wp-hook.php:348
WP_Hook:: do_action()
wp-includes/plugin.php:517
do_action()
wp-admin/admin.php:259
require_once()
wp-admin/tools.php:40
Hey, this error has been fixed in a recent version 🙂 please update 🙂
This is really a great tool. How come no one has build this before 🤔
Thanks. My woocommerce site was getting usable and kept crashing. I had done all of the usual things but then came across autoload. This saved my site (which has been going for 10 years). My stats are now
”
When you started on 2024-08-22 you had 2061 autoloaded options, for 2,797.2KB of memory. Now you have 1312 options, for 1,171.5KB of memory.
”
so 700 autoloads were removed and 1500kb removed from every download. My server stats are now looking a lot better and the website loads 1st time now rather than error pages or resource limit reached.
Still looking to see if I can take more off but some of the names are just googling rubbish.
Hi, if the source is Unknown, is it save to delete option ?
Does it mean that plugin is not installedor used anymore, so source is unknown?
Is it better to Remove autoload or remove option?
Removing autoload is a lot safer…
No. It means that the source is “Unknown”, not that the option isn’t used ever.
That’s great to hear!!
Great plugin. In a few days it found many options of plugins that were tested but no longer installed. Too bad I can’t use it. My site is running WP 6.6.2 and the plugin doesn’t allow me to delete the garbage it found. Thanks anyway.