Where Speed Is Lost: A Technical Guide to Adobe Commerce Performance Pitfalls
You can’t fix what you can’t see. And in Adobe Commerce, speed isn’t lost in one obvious place - it leaks out gradually, layer by layer, until the whole stack starts to feel heavier than it should.
 |  |
One second you’re “just checking Core Web Vitals,” and the next you’re knee-deep in flaky deployments, blocked main threads, and a TTFB (Time To First Byte) graph that is spiking like a heart monitor in a horror film.
And while all that’s happening behind the scenes, your customers?
They’re getting impatient. They’re bouncing. They’re buying somewhere else.
Because slow doesn’t just break metrics - it breaks trust. And when enough of your users feel it, your revenue does too.
This isn’t a frontend problem. It’s a full-stack problem. And in this guide, I want to show you where speed really disappears - not just in metrics, but in code, config, and architecture.
Let’s get into it.
1. The Stack Is a Liar
Most people start with Lighthouse. And that’s fine…it’s a good general-purpose snapshot and useful for diagnostics. But in the real world, lab tests don’t always match what users actually experience. Especially when the problem isn’t in your frontend bundle, but 8 layers deep in the deployment pipeline or database indexing logic.
Here’s a hard truth: You can pass Lighthouse and still have a painfully slow site. And you can fail it and still deliver a genuinely good experience.
That’s why at GENE, we don’t optimise for scores. We optimise for outcomes: faster TTFB, cleaner deployments, reduced regressions, and more conversions - all based on field data, not just lab results.
2. Layer One: Infrastructure Bottlenecks
The number of Adobe Commerce merchants running on hosting setups that haven’t been audited in 18+ months? Too many.
A few red flags we see regularly:
PHP workers bottlenecked on high-traffic events
Misconfigured Varnish or Fastly causing full cache misses, or a low cache hit rate
Cron Jobs and Queue Consumers overloading the database, and causing a spiralling slowdown
CDN set up but not properly configured.
Infrastructure issues tend to manifest as slow TTFB - the moment between request and first byte returned. We’ve seen client sites where TTFB regularly hit 1.2-1.5s, even for cached pages.
Quick wins:
Run TTFB checks across templates (not just homepage)
Add New Relic APM + browser to correlate server performance to frontend outcomes
Validate cache hit ratios in production, and then fix them
 |  |
|---|
3. TTFB and the Database Tax
TTFB isn’t always about hosting. In Adobe Commerce, it’s often a sign that your app is thinking too hard before it replies.
We’ve seen:
Overuse of synchronous plugins/hooks
Inefficient layered navigation filters triggering expensive joins
The same product loaded multiple times on a page
Overuse of redis caching, counterintuitively this can cause slowdown under heavy load
These issues don’t show up in Lighthouse. But they’re very real in New Relic flame graphs. One recent audit showed 200ms of request time going to a custom shipping module querying the entire postcode table on every page. Oops.
What we do:
Use New Relic to track actual query bottlenecks
Log slow SQL via MySQL slow log or Adobe profiler
Replace slow operations with indexed preloads where possible
4. Frontend: Themes, JS Bloat & the “Optimised” Lie
If you’re running a theme that’s been “optimised” without understanding what that means, chances are you’ve just shifted the mess around.
What hurts performance here:
Bloated JS bundles
Render-blocking third-party scripts loaded in the <head>
CLS caused by ad slots, review widgets, or slow-loading images without dimension attributes
CLS is often overlooked, but it's a critical part of Core Web Vitals. It’s not just about elements shifting on screen - it’s a sign that your site lacks visual stability. Google picks up on that, and so do your users.
What helps:
Use HTTP/2 and break JS bundles into smaller, targeted chunks
Audit all third-party scripts, and be ruthless
Implement a critical CSS strategy for above-the-fold content
Apply fixed dimensions or aspect-ratio containers to all hero media
5. Deployment Hygiene: The Forgotten Performance Layer
Here’s one for the devs: if your deploys take 30 minutes, block traffic, or occasionally corrupt frontend styles…your performance problems aren’t just in the app - they’re in your process.
I recently had a PR merged into Magento core that fixed a concurrency issue in LESS compilation. It caused intermittent failures during deploy, leading to corrupted frontend assets that required re-deploys to resolve. You know the ones - the ones where someone says “just redeploy it, that’ll fix the CSS.”
Turns out it was a race condition in the static content deploy pipeline. Subtle. Annoying. But fixable.
Deployment fixes we apply at GENE:
Zero-downtime deployment pipelines (CI/CD with proper health checks)
Static asset builds decoupled from app builds
Cache warming jobs post-deploy to eliminate the “slow first click”
(Disclaimer: This is not something I personally lean on if the stack is engineered properly, but a fair safety net if you’re working within legacy constraints or risk-averse environments)
6. The Slow Decay of Support
Here’s the part most agencies don’t talk about.
Even after you fix the frontend, tune the backend, and improve the deploy - performance still degrades if no one owns it. That’s why traditional “blocks of hours” support models fail.
They’re reactive. You raise a ticket. You wait. Something breaks. It gets patched. No one’s checking if performance slipped 5% last month.
With Unlimited Support, we monitor performance continuously. We benchmark it. We look for regression. And we maintain the state of performance, not just the output.
In Adobe Commerce, performance isn’t just a quick fix - it’s a system-wide property that has to be engineered from the ground up and continually refined. If your agency isn’t treating it that way, they’re not optimising your site - they’re firefighting.
 |  |
7. What We Do Differently
At GENE, our performance strategy isn’t to build faster sites. It’s to build sites that stay fast.
That means:
Monitoring performance with field data
Engineering fixes that are testable, repeatable, and safe to deploy
Embedding performance into the roadmap, not just the backlog
Educating clients on what metrics actually matter
Speed isn’t a number. It’s a signal.
And if your site feels slow, your customers definitely feel it.
They won’t send a ticket. They’ll just close the tab.
We build sites that stay fast. Because a fast site isn’t just better for your team - it’s better for your customers, your conversion, and your commercial future.
Want us to benchmark your performance against the best in Adobe Commerce?
We’ll find the bottlenecks, show you the graphs, and help you fix what your agency hasn’t even spotted yet.
Author
Luke Rodgers
Luke heads up engineering at GENE, where he spends most of his time solving hard problems for eCommerce teams trying to scale. He’s an Adobe Master Developer, long-time Magento contributor, and bug bounty hunter who cares deeply about performance, clean code and doing things properly.
He’s been instrumental in shaping GENE’s security tooling and performance frameworks, making sure the things we build are fast, stable, and easy to maintain. Whether it’s stabilising a flaky build, tuning infrastructure, or rethinking how checkout works, Luke’s focus is always the same: ship fast, run stable, add value.
Related Blog Posts
We surveyed and interviewed eCommerce decision-makers across retail, B2B, and DTC. The result? A brutally honest snapshot of what’s working, what’s not, and what’s coming next.
