Stop Installing 42 Plugins: How I Build Lean, Fast WordPress Sites Without the Bloat

Paul Dixon — Fri, 28 Nov 2025 20:03:22 +0000

At some point in every WordPress developer’s life, we inherit a site with a plugin list that reads like the credits of a Marvel movie — long, unnecessary, and full of things we’ve never heard of.

You scroll through it thinking: Why is there a plugin for breadcrumbs, three for forms, two for caching, and one that appears to exist solely to add a button that no one uses?

Welcome to modern WordPress.

But it doesn’t have to be like this. Not every site needs a plugin for breathing. Most sites — especially small business sites — will run faster, break less, and be easier to maintain if you build with intention instead of panic-installing another “all-in-one magical solution” that somehow weighs more than the rest of the site combined.

This is the approach I use at Ninja Tuna, where I build fast, accessible, SEO-friendly WordPress sites for small businesses. It’s not flashy. It’s not complicated. But it keeps client sites lean, predictable, and reliable.

Why Plugin Bloat Happens in the First Place

Most bloated installs aren’t built by bad developers — they’re built by overwhelmed ones.

A client asks for something quick → someone finds a plugin → that plugin depends on another plugin → the theme includes a “recommended plugins” installer → then marketing requests a pop-up → then the social team wants embedded Instagram feeds → then someone installs two security plugins because “more must be better.”

Suddenly the site loads like it’s streaming from a potato.

What’s really happening is this:

Plugins become substitutes for thinking.

When you don’t have a system, you reach for tools instead of solutions. And WordPress is very generous with tools.

My Approach: Start With a Lean Foundation

I start every build with one simple goal:

Use as little custom moving parts as possible — and make every part earn its place.

That means:

One clean, stable theme
One layout system
A handful of well-supported plugins
Custom code where it makes more sense than adding another dependency

If my plugin list scrolls, I already know something’s wrong.

This mindset alone prevents 80% of future chaos.

Skip the Page Builder Soup

One of the biggest things that wrecks performance is mixing layout systems.

You know the ones:

Elementor on some pages
Gutenberg on others
WPBakery lurking in the background from the old theme
Maybe even a rogue shortcode plugin throwing CSS in the header because… reasons

When I build a site, I commit to a single approach — usually Gutenberg with a strong theme.json, or ACF Blocks when I need something more structured.

It keeps markup clean, helps performance, and prevents clients from creating design chaos when they log in to “fix one thing” at midnight.

If a Plugin Does Something Simple, I Replace It With Code

A shocking number of plugins exist to do extremely small things:

Hide the WP version
Disable XML-RPC
Change the login logo
Add a custom post type
Remove a meta tag

These are five-line snippets — not plugins.

And when you replace ten tiny plugins with a single clean mu-plugin of custom code, the whole site becomes faster, more stable, and easier to maintain.

Plus, clients can’t accidentally deactivate it. (Ask me how many times I’ve had someone say “the site broke but I didn’t change anything” after turning off a critical plugin.)

Choose Plugins Like You’re Hiring Staff

A plugin shouldn’t be installed because it exists.

It should be installed because it’s earned its salary.

I look for:

Good documentation
Active updates
Devs who know how to enqueue scripts properly
Minimal data pollution
A focus on doing one job well
A reputation for not lighting your Core Web Vitals on fire

I don’t want a Swiss Army Knife plugin that tries to do 27 things.

I want a sharp, single-purpose tool I can trust.

Build Structure Into the Theme, Not the Plugin List

One of the reasons my sites stay lean is because structure lives in:

Block patterns
Template parts
Custom fields where necessary
Locked editing where clients shouldn’t touch
Theme.json for spacing, colours, typography, and consistency

When your system has predictable guardrails, you don’t need plugins to fix design problems later.

Clients can update content safely.

SEO stays intact.

Accessibility stays intact.

Performance doesn’t degrade every time someone adds a hero banner with eight animations and a Spotify embed.

Lean Isn’t Minimalism — It’s Intentionality

A lean WordPress build isn’t about running as few plugins as possible.

It’s about ensuring every piece of the system:

Has a purpose
Adds value
Doesn’t overlap
Doesn’t clash
Plays nicely with others
Won’t become a nightmare in three years

It’s like packing for a trip.

You can bring five coats if you want — but you’re the one who has to carry the suitcase.

The Result: Fast Sites, Happy Clients, Less Firefighting

When you build lean:

Updates stop being terrifying
Hosting stays cheap
Security improves
SEO gets easier
Page speed stops tanking
Debugging becomes actually manageable
Clients stop calling you because “the button disappeared again”

Most importantly?

The site stays trustworthy.

The future you (or future developer) will be grateful the whole thing isn’t held together with plugin duct tape.

If This Sounds Like the Kind of Site You Want

This is the exact approach I use at Ninja Tuna, where I build fast, accessible WordPress sites for small businesses — not Franken-sites stitched together from whatever plugin was on sale this week.

If you prefer your WordPress stack light, predictable, and built with intention, I’m your guy.

Forem: Paul Dixon