Macdoug

Here’s where I’ve landed after too many small client sites and too many cache plugins.

The temptation to over‑engineer a tiny brochure site is real. You spin up a basic site, then suddenly you’re layering page cache, object cache, image optimizers, database cleaners, and three different “performance suites” on top of each other. On a $10/month shared host for a five‑page site, most of that is noise. These projects usually don’t need a Rube Goldberg machine of performance tooling—they need sensible defaults, one or two well‑understood plugins, and a bit of discipline about how the site is built.

A lot of what drives that over‑engineering is marketing. Every plugin promises “up to 10x faster,” “perfect Lighthouse scores,” or “instant Core Web Vitals wins.” Clients see those promises, or read a random blog post that anoints a “#1 cache plugin,” and they expect the same result no matter how their site is actually put together. The problem is that those claims are usually made in a lab environment: clean site, no weird themes, no legacy plugins, no page builder chaos. Drop the same plugin onto a real client site with ten years of cruft, and the story changes fast.

Under the hood, most cache plugins are doing some combination of the same fundamental things: page caching, asset minification/combination, maybe some browser cache headers, and sometimes object caching integration. The differences that actually matter, in practice, are much less glamorous: how aggressive they are by default, how safely they handle logged‑in users and dynamic content, how clear the UI is, how noisy their “optimizations” are, and how well they play with your host. I’ve had far more trouble with plugins that try to “do everything” than with simple tools that stick to one job and do it predictably.

Client expectations and technical reality don’t always line up, so a lot of my job is translation. When a client says “make the site fast,” they usually mean “make it feel snappy to me and my customers.” They don’t actually care which plugin gets them there. That means I often end up explaining that shaving 200ms off a TTFB is less important than not breaking their checkout, or that their giant hero video is doing more damage than the lack of yet another cache layer. Sometimes the right move is to remove a plugin and simplify the stack instead of adding a new one.

So my current approach is pretty boring on purpose. For a small, mostly static site, I’ll usually pick one caching solution that I know behaves well on that host, turn on only the features I can explain in one sentence, and stop there. If the hosting platform already has solid server‑side caching, I lean on that first instead of piling on redundant tools. I’d rather have one simple, predictable setup that I can support a year from now than a fragile house of cards that scores well in a synthetic test but breaks whenever the client changes a setting they don’t understand.

If you’ve taken a different path—maybe you’ve standardized on a different set of plugins, or you’ve found a good way to handle more complex sites without drowning in edge cases—I’d love to compare notes. This is one of those areas where the theory and the marketing are straightforward, but the real‑world tradeoffs only show up after you’ve cleaned up enough messes.