There’s a particular kind of developer humiliation reserved for the moment you realise the solution to three weeks of performance hell was a single button click. I’ve had a few of those moments in my career. This one stung especially, because I’d been very confident it was going to be something clever.
We were on a performance sprint for a reasonably complex WordPress build hosted on a Hostinger Cloud container. The site had an allocation of 2GB of PHP memory, a fat 64MB OPcache interned strings buffer, the works. On paper, the hardware had no business struggling. In practice, the site was throwing 504 gateway timeouts on cold starts every time the cache got purged. You know the situation: the static HTML shield drops, and suddenly raw PHP requests hit the server all at once like the Boxing Day sales opening.
The complicating factor was that the architecture had quietly become a mess of competing ambitions. Cloudflare was handling edge delivery and asset minification at one end. A utility plugin called ASE Pro was throttling the Heartbeat API and sorting out image optimisation at the other. And sandwiched between them, LiteSpeed Cache was attempting to do all of the same things, competing with Cloudflare to minify CSS, throttling processes that ASE had already throttled, compressing assets that didn’t need compressing.
This is the plugin equivalent of three people trying to park the same car.
The obvious starting point was to strip out the overlapping features methodically. We killed the CSS and JavaScript minification routines first, since those were being handled upstream anyway. Then we cut the Object Cache and Guest Mode integrations on the suspicion that shared memory collisions were misbehaving. We even neutered the automated purge cascades that fired whenever you so much as looked at an image in the media library. Each change improved things slightly, worsened them slightly, or did nothing at all. It was, to use the technical term, a faff.
We were looking for the magic toggle. There wasn’t one.
One culprit turned out to be a database query hiding in plain sight: an ORDER BY RAND() command used to randomise a directory of fourteen local businesses on the homepage. Fourteen. Under any kind of load, MySQL was copying rows into temporary memory tables to shuffle them, which was grinding the server-level LSAPI connection pool to a halt. LiteSpeed Cache wasn’t causing the timeouts. It was just the unfortunate scapegoat sitting closest to the blast radius.
The fix was straightforward once we’d found it. We replaced the MySQL shuffle with a lightweight PHP transient that pulls and randomises the post ID array once per hour, entirely in memory. Database load dropped to effectively nothing.
With the underlying problem solved, the caching setup started to look rather redundant. Clean database queries return fast enough that you don’t need an aggressive static cacher managing a labyrinthine set of bypass rules on top of them. And with Cloudflare and ASE Pro already covering the edge delivery and background process management, LiteSpeed was essentially employed full-time to protect the site from a problem we’d now fixed.
So we deactivated it. Admin panel response times halved more or less immediately. Frontend stability returned. Nobody cried.
The lesson I took from this (and it’s not a particularly exciting one, which perhaps explains why it keeps needing to be relearned) is that caching plugins are compensatory tools. They exist to make slow things feel fast. If you actually make the slow thing fast, you often don’t need them, and the stack you’ve been layering on top of a rotten foundation can come down.
Boring advice: sort your database queries before you reach for a plugin. Expand your OPcache buffers. Check whether half your stack is duplicating what the other half already does. There’s a fourteenth-century philosopher whose name I won’t drop who said something along these lines. He was right. We just keep forgetting.