Too many WordPress plugins – if I had to name the single most common root cause behind the slow, fragile websites that land on my desk in Vienna, this would be it. Not bad hosting, not WordPress itself: 35, 40, sometimes 50 active plugins, half of which nobody on the team can explain anymore. Every one of them charges you a price, even the free ones. You just pay in a different currency: speed, security, stability and maintenance hours.
In this article I break down what each plugin really costs, show you the audit process I use in client projects, list the typical plugins you can replace with a few lines of code or WordPress core features – and explain when a plugin is still the right call.
The real price of every plugin
Speed
Every active plugin loads on every single page request, whether its feature is needed on that page or not. The classic case: a form plugin enqueues its CSS and JavaScript on all 200 pages of a site, although the form only exists on the contact page. Add autoloaded database options, extra queries and scheduled tasks, and the bill grows. In Query Monitor profiling sessions I regularly find individual plugins consuming 100 to 300 milliseconds of server time per request. Stack ten of those and the site feels sluggish before the first image even starts loading. I dig deeper into this mechanism in my article on why your website is slow and what actually helps.
Security
According to Patchstack’s annual security reports, over 90 percent of newly disclosed WordPress vulnerabilities are found in plugins – not in WordPress core. Every plugin is third-party code running with the same privileges as WordPress itself. Abandoned plugins are the worst offenders: once the developer stops shipping updates, every newly discovered vulnerability stays open forever. My rule of thumb: a plugin with no update for over a year and fewer than 10,000 active installs is a risk candidate by default.
Conflicts and update roulette
Plugins do not know about each other. Two caching plugins, two SEO plugins, or a page builder combined with an optimization plugin that mangles its scripts – these combinations produce the infamous white screen after an update. The math is unforgiving: with 40 plugins there are 780 possible pairings that can interfere with each other. No developer on earth tests against all of them.
Maintenance load
Each plugin wants updates, on average every few weeks. With 40 plugins that adds up to several hundred updates a year, and every single one can break something. Skipping updates just trades the stability risk for a security risk – a losing move either way. I explain why consistent care is non-negotiable in my post on WordPress maintenance and why it matters.
Database and backend weight
Less visible but just as real: many plugins write autoloaded options into the database that get loaded on every single request – including the options of that slider you deleted back in 2019. Add custom tables, transients and log data that nobody ever cleans up, and the database swells year after year. I have seen wp_options tables carrying over 20 megabytes of autoloaded data; the server hauls that ballast on every page view. The backend suffers too: each plugin loads its own admin scripts, notice banners and dashboard widgets, and your editorial team feels it with every click.
How I run a plugin audit
A plugin audit is not rocket science, but it needs structure. My process in client projects:
- Inventory: Every plugin goes into a list – purpose, date of the developer’s last release, number of active installs, and the question: who on the team knows what this is for? For a surprising number, the answer is nobody.
- Measure: With Query Monitor and a profiling tool such as Code Profiler I measure which plugins cost the most server time and database queries. The result almost always surprises the owner – typically two or three plugins are responsible for the bulk of the load.
- Categorize: Each plugin lands in one of three columns: keep (solves a real problem, actively maintained), replace (a leaner solution exists in code or core), delete (feature no longer needed or duplicated elsewhere).
- Test: On a staging environment I deactivate candidates step by step and verify the critical user flows. Never on the live site, never all at once.
One detail people get wrong: deactivated plugins must be deleted, not just switched off. Inactive plugin files still sit on the server and can remain exploitable through known vulnerabilities.
What you can replace with code or core features
Many plugins solve problems that WordPress now solves itself – or that fit into a few lines in a child theme. The most frequent candidates from my audits:
| Plugin type | Typical example | Leaner alternative |
|---|---|---|
| Homepage slider | Slider Revolution, MetaSlider | A static hero image with one clear message – better for LCP and conversion |
| Code snippets | Code Snippets, WPCode | functions.php in a child theme or a tiny site-specific plugin |
| Redirects | Redirection | Rules directly in the server config (.htaccess, nginx) |
| Google Fonts loader | Various font plugins | Self-hosted fonts in the theme – faster and GDPR-friendly |
| Analytics embed | Assorted tracking plugins | The snippet placed directly in the theme or via a tag manager |
| Post duplication | Duplicate Post | Block editor copy-all-blocks, or a 20-line function |
| Contact form with add-ons | Contact Form 7 plus four extensions | One lean form plugin without an add-on zoo, or a custom-built form |
Replacing a plugin with code pays off most where a 5,000-line plugin delivers exactly one feature that fits into 20 lines. Done properly – versioned in a child theme or a small site plugin so it survives updates – this is routine professional web development, not hacking.
When a plugin is the right choice
Let me be clear: plugins are not the enemy – unexamined plugins are. Some jobs would be reckless to rebuild yourself. E-commerce with WooCommerce, multilingual setups with Polylang or WPML, backups, payment forms, spam protection: these are mature solutions with years of development, security audits and enormous user bases behind them. You do not reinvent those.
My checklist before any new plugin goes onto a client site:
- Does it solve a problem we actually have – or a problem we might theoretically have someday?
- Is it actively maintained? Last release date, tested-up-to version, changelog quality.
- Does it have a meaningful user base and reachable support?
- What does it cost at runtime? Install on staging first and measure with Query Monitor.
- Does the feature already exist – in core, in the theme, or in a plugin we already run?
That last question is the most overlooked one. Feature overlap is the norm, not the exception: your SEO plugin already ships a sitemap, your caching plugin already optimizes images, your theme already bundles icons.
What decluttering actually delivers
A real example from my practice: a company website arrived with 38 active plugins, a homepage taking over four seconds to load and a wp-admin that made the editorial team dread every task. After the audit, 16 plugins remained. The result: server response time dropped from roughly 1.2 seconds to under 400 milliseconds, the homepage renders in under two seconds, and the backend is usable again. No caching tricks, no bigger server – just less dead weight.
The quiet wins matter just as much: fewer updates to shepherd, fewer possible conflicts, a smaller attack surface and a cleaner database. A site running 15 curated plugins is cheaper to operate over the years than one running 40 accidental ones.
Your plugin audit checklist
- Create a complete plugin list with purpose and owner
- Check each plugin’s last release date and active install count
- Measure runtime cost with Query Monitor on staging
- Identify duplicated features (sitemaps, image optimization, icons, fonts)
- Categorize every plugin: keep, replace, delete
- Replace micro-plugins with core features or a few lines of code
- Fully delete deactivated plugins, including database leftovers
- Document the outcome and repeat the audit yearly
Conclusion
Every plugin is a housemate in your WordPress installation: it consumes resources, demands attention and can cause trouble at 3 a.m. The best sites I look after run on 10 to 20 deliberately chosen plugins – not because minimalism is a virtue in itself, but because every single component has a reason to be there. Cutting plugin bloat is not about doing without; it is about deciding consciously.
If you suspect your website is carrying more weight than it should, I run plugin audits as part of my website care and maintenance service. Get in touch and we will find out together what your site actually needs – and what it can live without.
