A WordPress site rarely goes slow overnight. It chokes up gradually. A plugin here, a nice-looking feature there, and two years later the homepage takes four seconds to load while the owner wonders why the enquiries are drying up. We look after a handful of businesses in the west of Munich with exactly this pattern. And almost every time, it comes down to the same three plugin categories doing the most damage. Not because they are badly built, but because they get loaded for a job you could just as easily do at a fraction of the weight.
I'm deliberately writing about categories here, not specific product names. The reason: the makers change their plugins constantly, and a name I mention today might be far leaner a year from now. The pattern underneath, though, stays the same.
Why a page builder eats your load time
The first and heaviest category is the big page builders. Elementor, Divi, WPBakery. They are popular because you can click a page together without touching code. That's the deal. And you pay for that deal with CSS and JavaScript that loads on every single page view, whether you use half the features or none of them.
We measured this on a client site in Germering. The site ran on a widely-used page builder. Just for the layout, the browser was pulling in around 380 kilobytes of extra CSS and JavaScript before the first line of text was even visible. A good chunk of that was code for widgets that never appeared on the page at all. Carousels, countdown timers, pricing tables. All kept ready, none of it used.
What helps:
- Clean up globally. Many page builders have a setting like "Optimized Asset Loading" or "Improved Loading". On older installs it's often switched off. Turn it on, and at least only the CSS the page actually needs gets loaded.
- Pull your critical pages out of the builder. Build the homepage and your two or three most important landing pages as a clean template. Let the builder keep the sub-pages that rarely change.
- Drop it entirely, if you can. If you're overhauling a site anyway, a block theme or hand-built HTML is almost always faster. That's more work, but it holds up for years.
Honestly: removing a page builder completely is the most involved of the three fixes, because often half the site is built on it. If time and budget are tight, start with the next two points instead. They deliver a lot for very little risk.
The slider plugin nobody needs anymore
The second category is the all-in-one slider plugins. Revolution Slider, Slider Revolution, LayerSlider and the like. Ten years ago a slider like that was a status symbol. Every second site had a big animated slideshow up top. Today we know from a fair few usage studies that hardly anyone clicks past the first image. The payoff for the visitor is small. The weight it adds to your load time is not.
Here's the case that surprised even me. A tradesman's business in Emmering, right next to Fuerstenfeldbruck. The homepage loaded with an LCP of 4.1 seconds. Largest Contentful Paint, the moment when the biggest visible element has finished loading, is one of the Core Web Vitals Google uses in its rankings. 4.1 seconds is bad. We went through the plugins and found an active slider plugin. The odd thing: there was no slider on the page at all anymore. It had been taken out of the layout at some point, but the plugin kept running, loading its scripts and firing its database queries on every single request.
We deactivated it. Changed nothing else. The LCP dropped to 1.8 seconds. Visually, nothing changed for any visitor, because the slider had been invisible anyway. That's the kind of find that makes a look under the hood worth it.
What helps:
- Check whether the slider is even being shown. You wouldn't be the first business with a dead plugin running in the background.
- A single hero image instead of a slideshow. One good, compressed image with a clear message beats three rotating ones almost every time. Load times included.
- If it really has to move: the native image gallery or a tiny script is enough. A 300-kilobyte plugin for an effect hardly anyone sees is completely out of proportion.
The security suite that phones home on every click
The third category is trickier, because there's a genuine need behind it. Security. Plugins like Wordfence or iThemes Security protect against attacks, and that's a good thing. The problem isn't the idea, it's how some of these suites work. The heavy variants check against the database on every single page view, log every visit, cross-reference IP lists. Each of those queries costs time, and it costs it precisely at the moment the visitor is waiting for a response.
On an online shop client in Olching, we saw the security suite triggering several extra database queries per page view. In the server response time that added up to a good 200 milliseconds on average. Sounds like nothing. But for a customer clicking through five product pages, it stacks up. And the server response time is the foundation everything else is built on. If that's already slow, no amount of a lean front-end will save you.
What helps:
- Switch off live traffic logging. The feature that records every visit in real time is the biggest drain and almost nobody needs it running permanently. Turn it on for a targeted analysis, then off again.
- Firewall at the server level, not in the plugin. Many good hosts offer a Web Application Firewall that sits in front of WordPress. That's faster and takes the load off your database.
- Get the basics right. Up-to-date WordPress version, up-to-date plugins, strong passwords, two-factor at login. That covers a large share of attacks without a heavy plugin running along in the background.
How do you test this without breaking anything?
The most important point, saved for last. Don't deactivate a plugin blind on the live site of a working business. That can go wrong if other features depend on it. Here's how we do it:
- Measure first. A tool like PageSpeed Insights or a simple waterfall test shows you the baseline. Write down your LCP and server response time.
- Set up a copy of the site as a staging environment. Try there what happens when a plugin is off.
- Deactivate one plugin at a time, measure again each time and click through the site. That way you see straight away what buys you speed and what breaks something.
- Only once a change runs cleanly does it move to the live site.
This is no black magic, but it does cost a few hours of care. That's exactly what a lot of businesses don't put in, because day-to-day something more urgent always comes up. Understandable. It's just that the dead weight keeps growing in the meantime.
If you suspect your WordPress site is groaning under exactly this kind of dead weight, we're happy to take a look. We do a free website check where we name the biggest brakes for you, concretely, with measurements, not gut feeling. You can find more about our work under Web Design, and for the check just get in touch via our Contact page. We're based in Fuerstenfeldbruck and look after clients across the whole west of Munich, from Puchheim to Maisach.