Most small WordPress sites are slow, noisy, and fragile not because WordPress is bad, but because someone installed twenty plugins to solve two actual problems. Performance guides keep repeating the same advice – bad hosting, bloated themes, too many plugins – because those are still the main reasons sites crawl. And the pattern is always the same: a security plugin to feel safer, three cache plugins to feel faster, a “GDPR” plugin that doesn’t really block anything, and a page builder for every widget on the page.
This is a post about doing the opposite. Instead of “what can I install?”, the question is “what can I remove, and what do I actually need?”.
1. Start with the core: one theme, one cache, one security layer
Most performance checklists boil down to a boring recipe: decent hosting, a lightweight theme, caching, and image optimization. That’s it. The disaster begins when people try to “stack” solutions:
-
Two or three caching plugins fighting over .htaccess and headers.
-
Heavy multipurpose theme plus a full page builder plus a design plugin on top.
-
Security plugin + firewall plugin + “hardening” plugin, all doing the same job.
A small site doesn’t need that. Pick:
-
One maintained, lightweight theme.
-
One caching plugin (or server‑side cache if the host provides it).
-
One security layer (good host + basic hardening, maybe one plugin if you know why you’re using it).
Anything beyond that should be justified by a concrete use case, not by fear.
2. Don’t install a plugin just because a blog post scared you
Security and compliance articles are full of big numbers and scary fines. GDPR rules really are getting tighter, and regulators now expect real “prior consent” and proper blocking of non‑essential scripts. But the response on WordPress sites is often panic‑driven: install three cookie plugins, a “legal” plugin, and a random banner generator, all at once.
That doesn’t make the site more compliant. It usually means:
-
Tracking and analytics still fire before consent, because nobody checked the network tab.
-
Scripts are duplicated, pages slow down, and users see three different consent popups.
Instead of “install every plugin that mentions GDPR”, do this:
-
Map what you actually use: analytics, ads, embeds.
-
Pick one consent tool that can really block those scripts until opt‑in.
-
Configure it properly and test it. Then uninstall everything else.
Compliance is a configuration and testing problem first, a plugin problem second.
3. Fix the real bottleneck before chasing exotic optimizations
Most performance issues come from a few boring culprits: slow hosting, huge images, too many scripts, and database clutter. Yet people jump straight to “critical CSS generators”, “instant page”, or obscure database plugins before checking the obvious.
On a small site, you can usually get 80% of the gain by:
-
Compressing oversized images and using modern formats where possible.
-
Removing unused plugins and themes, especially ones that load scripts on every page.
-
Cleaning old revisions and spam comments, then adding a single, well‑configured cache.
Only when the basics are green in a tool like Lighthouse or WebPageTest is it worth thinking about preloading strategies and Core Web Vitals fine‑tuning.
4. Build for maintenance, not for the screenshot
Beginners often build for the first impression: a beautiful screenshot, lots of animations, and a plugin for every tiny effect. Later, updates become terrifying because every plugin update might break something.
A better rule set for small sites:
-
If you can do it with the block editor, don’t install another builder.
-
If a feature will be used once a year, don’t add a permanent plugin for it.
-
If a plugin touches critical things (logins, payments, forms), only install it if it’s actively maintained and has a clear reason to exist.
Think about who will maintain the site in three years. If the answer is “no one”, then your tech stack should be as boring and simple as possible.
5. My rule of thumb for plugins
The internet doesn’t need another list of “50 must‑have plugins”. It needs more people willing to say “no” by default. My rule of thumb for client sites is:
-
Default to 0 plugins.
-
Add one only if:
-
It solves a real, recurring problem.
-
WordPress core or a few lines of custom code truly can’t handle it.
-
I understand exactly what it does to performance, security, and privacy.
-
If you already have a plugin graveyard on your site, the best optimization might be a removal spree, not another install.
If you want help untangling a WordPress site that’s buried under plugins, or you’re trying to get real GDPR‑style consent instead of another banner that lies to users, that’s exactly the kind of problem I like working on.