The situation
A membership community built on WordPress with WooCommerce and BuddyPress — recipes, member profiles, an activity feed, paid access. It was slow, and it had been “optimised” more than once by the usual route: install a caching plugin, install another caching plugin, buy a bigger server.
None of it worked, because none of it addressed what was actually wrong.
What we did
Found the real bottleneck. The site wasn’t slow because pages weren’t cached. It was slow because the PHP opcode cache was saturated — the stack was large enough that compiled PHP no longer fit, so the server was recompiling code on requests that should have been nearly free. That is invisible to every front-end performance tool. It shows up only when you look at the runtime itself.
This is the single most common pattern in performance work: the thing everyone is tuning is not the thing that is slow.
Rebuilt the community layer properly. The stock activity feed was doing the platform no favours. We rebuilt it as a familiar social feed — the interaction pattern every member already understands from elsewhere — implemented through child-theme template overrides rather than plugin sprawl, so the platform stays updatable.
Kept core features reachable. Recipe content that was locked behind a plugin tier was made publicly renderable through a small purpose-built extension, rather than paying an annual licence for a single capability.
Why it mattered
Two lessons that generalise well beyond this project.
First: measure the runtime, not the symptom. A site can be perfectly cached and still slow.
Second: on a mature platform, the cheapest feature is usually the one you build against the platform’s own extension points — not the one you buy, and not the one you fork.