- Plugins add PHP execution overhead before they can provide any performance benefit.
- A caching plugin still has to run PHP on every request just to decide whether to serve its cache.
- Bot and attack traffic is best filtered before it reaches PHP — by a firewall in front of the site, not a plugin inside it.
- Removing overlapping performance plugins reduces conflicts and improves site stability.
The Plugin Performance Paradox
WordPress plugins are incredibly powerful. They extend functionality, add features, and let site owners customise almost anything. But when it comes to performance, plugins create a paradox: the tools designed to speed up your site are themselves slowing it down.
Every plugin you install adds PHP code that must be executed on every page load. Caching plugins, security plugins, image optimisation plugins — they all add overhead before they can deliver their benefits. It's like hiring a personal trainer who makes you carry them on your back during the workout.
How Plugin-Based Caching Actually Works
When you install a caching plugin like WP Super Cache or W3 Total Cache, the plugin intercepts WordPress's page generation process. It saves a static HTML copy of each page and serves that copy to subsequent visitors.
The Hidden PHP Tax
The caching plugin itself must load on every request to determine whether to serve a cached page or generate a fresh one. This consumes CPU cycles and memory that could be used to serve actual dynamic requests.
The more durable fix is to take work away from PHP altogether: filter junk traffic before it reaches the server, give the site dedicated resources so a neighbour can never consume its capacity, and move jobs like backups and monitoring out of WordPress and into the platform.
The Image Optimisation Problem
Image optimisation plugins face similar challenges. They typically work by intercepting image uploads, processing them through compression algorithms, and storing optimised versions.
The cheapest optimisation is the one your server never has to do: export images at the size they will actually be displayed, compress them before upload, and lazy-load anything below the fold with the native loading="lazy" attribute.
What the Hosting Layer Should Own
The alternative is to move performance concerns out of WordPress entirely. Isolation, traffic filtering, backups and monitoring are infrastructure jobs — when the hosting layer handles them, WordPress is free to do what it does best: manage content.
How G7Cloud approaches this
Every site runs in its own dedicated container with its own database, so a neighbour's traffic spike can never consume your resources. ScaleShield (WAF + bot protection) drops junk traffic before it reaches PHP, and backups and uptime monitoring run at the platform level — not as plugins.
That leaves plugins doing the one thing plugins are genuinely good at: adding features to your content. Fewer moving parts inside WordPress means fewer conflicts, fewer updates to babysit, and more predictable performance.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud — UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →