A client once told me, “We have 50+ plugins installed — can you just add one more?”
I said no. Then I removed 30 of them instead.
This is the full story of what that project actually involved — the problems I inherited, how I diagnosed them, what I built to fix them, and what changed for the client as a result.
The Context
I worked as a Senior Full Stack WordPress Developer at a digital agency, where I took ownership of four live client websites. These weren’t small brochure sites — they were active, content-heavy platforms serving real traffic, real leads, and real revenue for the businesses behind them.
When I took over, all four sites shared the same underlying issues.
The Problem Statement
Here’s what I walked into:
- 50+ plugins per site, many overlapping in function or barely used
- Two page builders running simultaneously — Elementor and WPBakery, installed on the same sites
- Headers and footers built inside the page builder itself, which meant CSS conflicts were breaking layout almost daily
- Zero documentation — no record of what each plugin did, why it was added, or what would break if it was removed
- No custom-coded solutions anywhere — every requirement, no matter how small, had been solved by installing another plugin
None of this is unusual for WordPress sites that have grown organically over years without a developer auditing the stack. But it creates a compounding problem:
Every plugin is a dependency. Every dependency is a potential security hole. Every security hole is a performance drag. Every performance drag costs rankings, speed, and ultimately, leads.
The sites weren’t broken in an obvious way — they worked. But they were fragile, slow to update, and expensive to maintain in ways that weren’t visible until you tried to change something and three unrelated things broke.
Diagnosing the Real Issue
Before touching any code, I audited each site plugin-by-plugin to understand:
- What each plugin actually did
- Whether its function could be replaced with a small amount of custom code
- What depended on it — templates, shortcodes, page builder modules, other plugins
- Whether removing it would have any downstream effect on existing content
This mattered because the instinct with plugin-heavy sites is often to “clean up” aggressively and fast — which is exactly how sites break in production. The real skill here wasn’t knowing how to remove a plugin. It was knowing which plugins were load-bearing and which were dead weight, and sequencing the work so nothing client-facing ever went down.
The Fixes and Implementation
Across all four sites, over roughly three months, I delivered:
1. Removed 30+ plugins per site Each removed plugin was replaced with clean, custom-coded functionality — built specifically for what that site needed, nothing more. No unused settings panels, no bloated dependencies, no unnecessary database calls on every page load.
2. Rebuilt headers and footers outside the page builder entirely This was one of the highest-impact fixes. Headers and footers had been built as page-builder templates, which meant every style conflict between Elementor and WPBakery surfaced there — daily. I rebuilt them as proper theme-level templates, decoupled from either builder. Result: consistent rendering across every page, and the daily CSS-conflict firefighting stopped completely.
3. Built custom PHP functions for site-wide changes Rather than manually editing content or relying on a plugin to bulk-edit pages, I wrote custom functions that could push changes across thousands of pages in minutes. What used to take days of manual updates (or a risky bulk-edit plugin) became a controlled, repeatable process.
4. Improved PageSpeed and Core Web Vitals With 20+ fewer plugins each loading their own scripts and stylesheets, and with headers/footers no longer relying on page-builder rendering, load times and Core Web Vitals scores improved measurably across all four sites. Pulling the real field data (CrUX, mobile) for one of the sites over this period shows exactly why that matters:
- Cumulative Layout Shift (CLS) dropped from a “Poor” 75th-percentile score of roughly 0.30–0.34 down to a consistent “Good” score of around 0.01–0.02 — a direct result of pulling headers and footers out of the page builder, where competing Elementor/WPBakery CSS was causing visible content jumps as pages loaded.
- Interaction to Next Paint (INP) improved from the “Needs Improvement” range (around 220–250ms) into the “Good” range (roughly 140–160ms), reflecting the reduced JavaScript overhead from stripping out 30+ plugins that no longer had to initialize on every page load.
Both metrics moved from failing Google’s Core Web Vitals thresholds to comfortably passing them — not through a caching plugin or a quick fix, but as a direct consequence of removing the architectural bloat causing the problem in the first place.
5. Documented everything Every custom feature — what it does, how it’s configured, how to update it — was documented for the client. This wasn’t an afterthought. A site is only actually maintainable if the people running it day-to-day can understand what’s under the hood without calling a developer every time.
The Result
By the end of the engagement, all four sites were running leaner, faster, and more reliably — with a fraction of the plugin dependencies they started with and none of the daily layout breakage that had been treated as “normal.”
My manager at the time, Jasmine Sedgwick (Strategic PR and Digital Marketing consultant), summarized the engagement in a LinkedIn recommendation, noting that I took ownership of four websites and consistently kept them performing at a high standard, and specifically called out the reduction from over 20 plugins to custom-coded solutions as one of the standout achievements of the work — alongside the custom functions built to roll out changes across thousands of pages efficiently.
The Bigger Lesson
Here’s what most people don’t realize about plugin-heavy WordPress sites: the plugins were never really the problem. The problem was that no one had ever treated these websites as something worth engineering properly.
Installing a plugin is easy. Knowing when not to — and building something smaller, faster, and purpose-built instead — is the actual skill.
If a WordPress site is being held together by 50 plugins, two page builders, and a bit of luck, that’s not a hosting problem. It’s an architecture problem.
This is exactly the kind of problem I built CraftyWebbies to solve — a development agency focused entirely on WordPress, built on the principle that most sites don’t need more plugins, they need less bloat and more custom-engineered code that’s actually built to last.
If your site feels like it’s held together the same way, drop it in the comments or send me a message. I’ll tell you honestly what’s actually slowing it down.