A few years back, I was brought in to “speed up” a luxury apparel site doing over $20M in annual sales. The CTO thought it was just a CDN tweak or two. Their dev team thought it was “probably a caching thing.”
Turned out, the real bottleneck was something nobody had looked at in years: a hidden image-processing job buried deep in a vendor’s API that ran every time a product page loaded.
On paper, everything about their setup looked “by the book.” It passed Lighthouse audits. The docs for each tool said they were using it correctly.
But the system as a whole had quietly developed inefficiencies that only years of real-world use could reveal.
That project was the start of a pattern I’ve seen in almost every big optimization job since: the biggest performance gains usually come from problems you’ll never find in the official documentation.
The myth of “just follow the docs”
If you’re building a fresh project, documentation is your best friend.
If you’re scaling a monster that’s been alive for a decade? Documentation becomes a polite lie.
Why? Because docs tell you how it should work, not how it’s actually behaving in your messy, battle-worn stack.
- The docs won’t mention that your database query planner starts behaving differently once you hit a certain row count.
- They won’t warn you that a third-party script’s performance can tank when a vendor quietly adds a new tracking endpoint.
- And they definitely won’t tell you that a background job from five years ago is still running and competing for CPU during your busiest checkout hours.
I’ve lost count of the times I’ve been called in after a team “optimized” something according to the docs… and actually made it slower.
My personal rule for hunting hidden performance wins
After enough late-night debugging sessions, I started following a simple framework before touching any new tool, setting, or optimization technique.
1. Find your “real world” workload.
Not the test data. Not the staging server. The exact conditions your production system faces during peak load. That’s where you see the true bottlenecks.
2. Look for the silent killers.
Jobs that run without anyone realizing. API calls with no visible UI impact. Middleware that processes every request but never shows up in the obvious metrics.
3. Map ownership.
In big stacks, there are components nobody is “responsible” for anymore. Those tend to rot quietly and slow everything else down.
This process isn’t glamorous, but I’ve seen it shave seconds off page loads without touching the front-end code at all.
The E-commerce trap
High-revenue eCom stacks are especially prone to invisible performance bloat.
Why? Because when you’re doing $100M+ a year, you’re constantly bolting on features – seasonal landing pages, custom upsell flows, new loyalty programs.
And each addition introduces little bits of complexity that never get revisited because “it’s working.”
Over time, that complexity compounds into a system where the cost of one checkout request might be 4x higher than it was when you launched… even though your pages look exactly the same.
The scary part? You’ll feel it in your infrastructure bill and in your conversion rates long before you notice it in your speed scores.
What to optimize first (that docs won’t tell you)
When I take on a big optimization project, I usually start with three “hidden zones”:
- Third-party scripts – Especially anything loaded asynchronously “for performance” but actually chewing up main-thread time.
- Internal APIs – Not just latency, but how they behave under burst loads and whether they retry in ways that cause cascading slowdowns.
- Background jobs & queues – Especially image processing, data exports, and cron tasks that run during high-traffic windows.
I’ve seen sites go from 4-second to sub-second Time to Interactive just by fixing issues in these three areas – without touching their public-facing assets.
The bottom line
Docs are where you start, not where you finish.
If you want to scale a mature eCom stack without drowning in performance debt, you have to hunt for the ghosts – those undocumented processes, leftover integrations, and silent inefficiencies that never make it into the official playbook.
That’s where the real speed lives.
See you next week.