The plugins you forgot are slowing your site

Three days into a wordpress speed optimisation job and I was still looking for something that was broken. I’d been through the hosting, the server config, the theme. Elementor wasn’t the problem. Everything I checked came back clean, and the backend editor was still taking nearly a minute to open.

At some point I stopped looking for something wrong and started looking for something that was working exactly as it was supposed to, just pointed in the wrong direction.

It was a widget add-on plugin. One of the popular ones that extends Elementor with extra components. Perfectly functional. Loading all eighty of its components on every page, every session, whether or not any of them were in use. That’s what it does out of the box. Nobody had ever opened the module manager and told it to do anything different. The number of those widgets actually used across the whole site: three.

The wordpress speed optimisation issue that gets skipped

This version of the problem doesn’t come up much in conversation. Not the plugins that were installed and forgotten. The ones that are actively in use, just not anywhere near as much as they’re loading.

Widget add-on plugins for page builders tend to ship this way by default. Everything activates, everything loads, and it keeps loading on every page until someone goes in and turns off what they’re not using. The plugin is behaving exactly as designed. It just never got configured.

The performance difference after trimming that list is significant. It’s one of the first things I look at on any site running a widget library, because it’s almost always sitting there untouched.

The plugins nobody remembered installing

The more common version of the problem looks different. Not bloated components from an active plugin. Just things that have no current reason to be there. A campaign plugin from a promotion that wrapped up two years ago. Nobody thought to remove it because nobody thought about it at all.

Every active plugin adds something to the page load. Stylesheets, JavaScript files, database queries. They all stack. A site with ten or twelve of those running quietly in the background just feels slow. Not broken. Slow. And that’s enough.

I went through a site that had forty-seven plugins installed, eleven of them deactivated. After the audit, the active count came down to nineteen. The site got measurably faster before anything else changed. No hosting upgrade, no image compression, no theme edits. Just fewer things running.

The ones that were deactivated but never deleted

A deactivated plugin isn’t loading on the front end. But the code is still sitting in the file system, unmonitored. Wordfence publishes a vulnerability feed that tracks how often plugin vulnerabilities get discovered and which ones are affected. Certain types carry more risk even when inactive: file access plugins, form handlers, redirect managers. The code doesn’t need to be running to be a problem.

Deactivated and safe are not the same thing.

What the audit actually came down to

One question per plugin: what is this doing right now. Not when it was installed. Right now. The ones that couldn’t answer that got deactivated and tested. If nothing broke, they got deleted. The deactivated list got cleared out entirely.

For the widget add-on, I went into the module manager and turned off everything that wasn’t in active use. Editor load time dropped. Front-end performance improved. That was before anything else got touched.

A caching plugin like WP Fastest Cache works a lot better once the list underneath it is clean. Layering performance tools on top of an unaudited plugin list mostly just adds more things to the stack.

The whole audit took under an hour. That’s usually how it goes. The time isn’t the obstacle. It’s knowing what question to ask about each one.

It’s one piece of a bigger picture. The rest is here.

If that’s something I can help with on your site, I’m around.