A WordPress site rarely gets slow or fragile in one go. It gets there one reasonable decision at a time.
The contact form gets spam, so a plugin goes in to stop it.
The home page needs a slider, so another plugin. Someone says the site is slow, so a plugin to speed it up.
Then a plugin for the cookie banner, one for the popup, one for the social icons in the footer.
Each fix makes sense on the day. Two years later the site is running forty of them, and nobody can say what half of them do.
That’s the pattern: plugins used as patches. Something hurts, so you cover it with a patch, and nobody asks why it hurts.
Each plugin is someone else’s code
A plugin is code written by someone outside your business, updated on their schedule, for their reasons.
Some are built by large teams who fix problems within days. Some are built by one person in their spare time, who moved on years ago.
You don’t see the difference from the outside. Both install with one click.
This is where most of the risk on a WordPress site comes from.
Of the 11,334 new security holes found across WordPress in 2025, 91% were in plugins and 9% in themes.
WordPress itself accounted for six.
Nearly half weren’t fixed by the time they were made public, so for a while there was nothing to update to.
Every plugin you add is a promise that someone else will keep their code safe, for as long as your site runs.
The more plugins, the more promises, and the more people you’re relying on to keep them.
Every plugin costs speed, on every page
Most plugins load their own files on every page of your site, whether that page uses them or not.
The slider’s code loads on your contact page.
The form’s code loads on your blog posts.
None of it is much on its own. Forty of them together is why a site feels sluggish on a phone, and visitors who wait leave.
The usual answer to a slow site is, of course, another plugin.
Plugins also break each other
An update that installs without a problem can still break a page, because plugins share the same site and don’t always agree.
When something stops working after an update, the question is which of the forty did it. Finding out takes time, and on most sites nobody is checking.
What we do instead
We start from the other end.
A plugin has to earn its place: it does something important, it’s well looked after, and doing the same job ourselves would be worse. A few do earn it, and we use those.
Most small jobs don’t need one.
A few lines of code that we write and own often do what a plugin would, without the extra files, the outside updates or the stranger’s promise.
The result is a site with fewer moving parts.
That’s what makes it fast.
It’s also what lets us check every update properly and promise that a bad one gets rolled back.
It’s the same reason installing plugins stays with us rather than with you: the keys to the parts that break things are what make those promises keepable.
Plugins aren’t the enemy
This isn’t a case against plugins.
Being able to add almost anything is a big part of why WordPress runs so much of the web, and some jobs really do need one.
The problem is reaching for a plugin first, every time, without asking whether the site needs it, or who will look after it in three years.
Three questions for whoever looks after your site
- How many plugins does it run, and what does each one do?
- Which of them haven’t been updated in the last year?
- If one is abandoned tomorrow, what’s the plan?
If those questions get a clear answer, good. If they get a shrug, it’s worth a second look before something breaks.