Lighthouse is a lab test
One page, one device, one network, usually with a warm cache. Useful for isolating a cause, not for reality.
Magento performance audit
Anyone can send you a Lighthouse score. We profile the whole store, including the pages Core Web Vitals never looks at, then tell you where each second goes.
Adobe Commerce gold partner
#1 Adobe Commerce partner worldwide
Hyvä Platinum Partner
40+ projects delivered
ISO certification
9001 & 27001
Most certified Hyvä agency worldwide
200+ Adobe Commerce Certifications
Magento Association
Platinum Partner
Trusted by brands globally
A speed score is not a diagnosis
Every agency can run Lighthouse. It can't say which second belongs to which cause, or if your theme can hit the target.
1.7s
between the lab score you were comfortable with and what customers actually wait. Google ranks on the second.
MetricLabField, 75th pctVerdict
LCP
2.9s
4.6s
FailINP
190ms
410ms
FailCLS
0.04
0.19
Needs workTTFB
610ms
1,240ms
FailScore
71
Not a ranking input
n/aCore Web Vitals measure the shop window. Not the till
They're measured on anonymous visitors loading cacheable pages. Everything below is invisible to a Lighthouse run, uncacheable by design, and sits between a visitor and an order.
Cart and checkout
Never cached, always rendered live, and the slowest part of most stores.
Logged-in customers
Account pages, order history and B2B pricing bypass the cache. Your best customers get the slowest store.
Admin and operations
Order grids, product saves, imports. Not a ranking factor, and a daily cost to your team.
Customer section loads
Magento's own AJAX calls fire on nearly every page, uncached. Slow ones make a fast page feel broken.
Search and layered navigation
Every filter click is an uncached query against a large catalog.
Background work
When cron and consumers stall, nothing renders slowly. Orders just stop reaching the ERP.
APIs and integrations
Headless, mobile, marketplace and ERP traffic. Real load, absent from any page-speed tool.
Lab numbers are a simulation. Field data is what happens
This is the difference between an audit and a screenshot, and almost nobody in this market draws it.
Core Web Vitals are field measurements
Real users, real devices, at the 75th percentile. That's what Google ranks on, and it's routinely worse.
We audit against both
Lab to attribute causes, field to establish reality. Where they diverge, the divergence itself is a finding.
If an audit you've been given contains only a Lighthouse score, it measured the wrong thing
What a second is actually worth
Speed work loses the budget argument whenever it's presented as a score instead of a number. We model it against your own analytics.
Conversion
The measured relationship between load time and conversion on your own store, by device.
Abandoned before they arrived
Sessions that never render, weighted by the traffic source that paid for them.
Rankings
Core Web Vitals are a confirmed ranking input. The audit says which templates are failing.
Peak
What the same problem costs on your biggest day, when every weakness amplifies.
Two kinds of slow store, and they need opposite work
Paying for the wrong lane is the most expensive mistake in performance work, and it's why so many optimizations underdeliver. Most stores are some of both, in a ratio the audit measures rather than assumes.
Render-bound
Typical of brand and content-led stores. The seconds are in the browser: theme JavaScript, blocking assets, oversized media, third-party tags.
Frontend engineering, ceilinged by your theme
Response-bound
Typical of large catalogs and B2B. The seconds are behind the request: TTFB, queries, indexers, cache misses, search.
Backend engineering, untouched by image work
What good actually looks like on Magento
Most merchants have never been told what a healthy number is, which makes it impossible to know whether a quote is ambitious or lazy.
TTFB, cached page
- Target
- Under 150ms
- Typical
- 400ms to 1s
Adobe's own guidance: a cacheable page should serve in under 150ms if Varnish works
TTFB, uncached page
- Target
- 200 to 500ms
- Typical
- 1 to 3s
Uncached is cart, checkout and logged-in browsing. Most stores never measure it
Full-page cache hit rate
- Target
- 90%+
- Typical
- 55 to 75%
Below 85% is a finding. Every miss is a page rendered that shouldn't have been
LCP, field
- Target
- Under 2.5s
- Typical
- 3.5 to 5s
A Core Web Vital and a confirmed ranking input
INP, field
- Target
- Under 200ms
- Typical
- 300 to 600ms
Where Luma stores usually fail
CLS, field
- Target
- Under 0.1
- Typical
- 0.1 to 0.3
Cheap to fix, often overlooked
Reindex duration
- Target
- Off-peak
- Typical
- Unknown
Nobody measures it until it collides with a campaign
Server response, decomposed
Time to first byte is where most Magento slowness lives, and it's a single number hiding six different problems. We take it apart.
One average, two realities
An average TTFB is meaningless when half your requests are served in 40ms and half hit PHP. The ratio is usually the finding.
HIT versus MISS, separately
Two numbers plus the ratio. The ratio is usually the finding.
PHP, database and external time
Every slow request split into where the time was actually spent.
Third-party calls in the request path
A live ERP stock check or tax lookup puts someone else's latency inside your page load.
Session and cache backend latency
Session reads happen on every uncached request. A network hop slows everything logged-in.
Search query time
What search actually costs on listing pages at your real catalog size and facet count.
Connection setup
TLS, HTTP/2 and keepalive, which add hundreds of milliseconds no application fix touches.
OPcache and runtime config
A two-line change that quietly taxes every uncached request when it's wrong.
Profiling, down to the function and the query
Synthetic tests tell you a page is slow. Profiling tells you which function, query and background job is responsible, on real traffic, over time.
Ranked by total time, not slowest
A 400ms controller called 90,000 times costs more than the transaction that runs twice a day.
Segment breakdown per transaction
The difference between the category page is slow and one plugin adds 340ms to every render.
Slow query analysis
Aggregate cost with query plans, so N+1 shows as one query times two hundred.
External service calls
Latency and error rate per outbound call, so a degraded supplier API is a finding not a mystery.
Cron, consumers and indexers
Which jobs run long, which have quietly stopped, which overlap, which run at peak.
Error rate alongside response time
A fast 500 is not a fast page, and spikes usually share a cause with slowness.
Your code versus Magento's
Whether three custom modules account for 60% of the render. It changes who owns the fix.
Percentiles, not averages
The average hides the tail. The 95th is where customers actually feel the store.
Correlated with deployments
It got slow around March becomes it got slow on the 12th, in this release.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Where you already run application monitoring we use your data. Where you don't, we instrument for the audit and leave the instrumentation behind, so you keep the visibility.
Caching strategy, end to end
Almost every Magento store has caching enabled. Far fewer have caching that works, and the gap is usually the biggest number in the report.
Hit rate, measured per template
Read from varnishstat rather than assumed, so the number is real.
Miss versus pass, different problems
A miss is fixed by warming. A pass is an application bug wearing a caching costume.
What makes pages uncacheable
One non-cacheable block takes its whole page out, and a bad module can take the catalog.
Cache tags and blast radius
We trace what a routine merchandising edit actually invalidates.
Warming and the cold window
Magento's cache is lazy. Every deploy hands real customers uncached pages until traffic warms it.
Varnish health beyond hit rate
Grace hits, ban-list growth, thread queueing and LRU evictions, each with its own meaning.
Varnish configuration
VCL against the reference, grace mode, probes, ESI, and whether purges actually arrive.
Redis or Valkey topology
Separate instances, or one where a cache flush logs your customers out.
Customer section and private content
Magento's uncached AJAX calls. Slow ones make a fast page feel broken.
Browser and CDN layers
Asset TTLs, headers on uncacheable routes, and whether the CDN shields your origin.
Full-page cache: 61% of requests actually served by Varnish. Two in five pages rendered that never should have been. Healthy is 90%+. Below 85% is a finding.
Background work, indexers and queues
Nothing here renders slowly. It fails quietly instead, and the first symptom is usually commercial rather than technical.
Cron health and collisions
Which groups overlap, which run at peak, and whether anything has been stuck for weeks.
Indexer mode and duration
Update-on-save on a large catalog turns every product edit into a stall.
Queue consumers
Whether they run at all, backlog depth, and what's waiting behind them.
Schedule table health
cron_schedule bloat, which slows the mechanism meant to be maintaining the store.
Frontend, render path and the rest
Everything the sections above don't cover, measured on your templates and attributed to a cause rather than listed as an opportunity.
Field and lab data
Home, category, product, cart and checkout, with real-user data plus lab runs for attribution, on mobile and desktop.
- Five templates, both devices
- Field data at the 75th percentile
- Lab runs for cause attribution
- Divergence recorded as a finding
Frontend and render
JavaScript weight and execution, blocking assets, critical CSS, fonts, the image pipeline, and the LCP element identified rather than guessed.
- JavaScript weight and execution
- Render-blocking assets
- Font and image delivery
- The LCP element, named
Third-party tags
Every tag measured for what it costs in milliseconds, on which templates, so removing one is a numbers conversation.
- Cost per tag, in milliseconds
- Which templates each loads on
- Blocking versus deferred
- What removal would recover
Extension load
Every module weighed for its performance cost, including the ones nobody remembers installing.
- Cost per installed module
- Frontend versus backend impact
- Disabled but still loading
- Overlapping functionality
Infrastructure
Whether the stack underneath can deliver what the code is capable of, with a handoff to the infrastructure audit when the answer is no.
- Resource headroom
- Service configuration
- Delivery and CDN
- Handoff where the stack is the limit
Database
Slow query log, index coverage on custom tables, buffer pool against dataset, and the queries your own custom code generates.
- Slow query log
- Index coverage on custom tables
- Buffer pool against dataset
- Queries from your own modules
Admin performance
An unusable admin is a real cost your team pays daily, and it's rarely in anyone's audit scope.
- Grid and save times
- Reindex impact on the admin
- Bulk operation behaviour
- Time your team loses per day
Can we get there without a rebuild
Legacy Luma ships megabytes of RequireJS and jQuery that block the main thread. The honest question is whether your theme has a ceiling below your target.
What tuning can still buy
Measured, with the gains attributed, so you know the value of the cheaper path first.
Where the ceiling actually sits
Some Luma stores reach good vitals. Many can't, and no backend work lifts them. You get a verdict, not a hedge.
What a rebuild delivers, and costs
The most certified Hyvä agency in the world, having migrated Drybar, OXO and Lichtkoning off legacy themes.
And when it isn't the answer
Plenty of stores are told to rebuild when the real problem is a 1.2-second TTFB. We'll say so.
vs targetWill it hold on your biggest day
A store comfortable at 200 concurrent users can fall over at 900, and the failure mode is rarely the thing you optimised.
Load behaviour under real traffic
Where the store degrades, what breaks first, and at what concurrency. Tested, not estimated.
Headroom against your actual peaks
Your last campaign's real numbers against what the current configuration will carry.
The cold-cache scenario
What happens when a deploy or scale-out hands real traffic uncached pages. That's how peak incidents start.
Included where peak readiness is the reason for the audit. Otherwise scoped separately, because load testing on a live store deserves planning.
AI correlates the evidence. Engineers decide what to do
Findings live in places that rarely get read together: the profiler, the codebase, the cache counters, the database. Correlating them is what AI is genuinely good at.
What AI does
Reads code against measured behaviour
Profiling says where the time goes, the code says why. Traced to the loop, plugin or observer causing it.
Cross-checks the evidence types
Findings that agree across sources are real. Findings in only one usually aren't.
Recognises the pattern, not the instance
The same anti-pattern often appears in six modules. A manual review finds the one it opened.
Proposes where a layer belongs
Queue, block cache, index time or removed entirely, with the trade-offs compared quickly.
And where a layer should come out
A caching layer without hit rate, a module reimplementing the platform. Removal is a real recommendation.
What only an engineer does
Decides cause versus symptom
Correlated evidence narrows the field. Judgment picks the one to act on.
Weighs the fix against the risk
A correct change that touches checkout during peak season is not a good recommendation.
Chooses the order
Which single finding, once fixed, makes four others disappear.
Signs the report
AI correlates and proposes. People are accountable for what you're told to do.
Profiler
Category render spends 340ms in one plugin
Codebase
That plugin loads a product collection inside a foreach
Database
217 near-identical queries per request
Cache counters
Passes climbing on the same template
Your code and data stay inside our ISO 27001 practice and are never used to train a model.
What you receive
Hours against expected seconds, so the roadmap sorts itself by value rather than by our preference.
An anonymised sample report, before you commit
You should know what you're buying before you buy it.
Your real numbers, field and lab
Core Web Vitals, TTFB and throughput per template, with the divergence explained rather than hidden.
A root cause behind every finding
Not the product page is slow, but 1.9 seconds of scripts, of which 1.2 is one tag.
Effort and gain, per fix
Estimated hours against expected seconds recovered, so the roadmap sorts itself by value.
A revenue model
What the current state costs and what recovering it is worth, against your own analytics.
A straight theme verdict
Whether tuning gets you to good vitals, or whether you've hit the ceiling.
A walkthrough with the engineer who ran it
And an anonymised sample report before you commit, if you want to see the quality first.
A statement of what wasn't measured
Recorded, so no area is presented as healthy by omission.
An AI tool lists problems. This one ranks them by worth
AI analysis is part of the audit, not the point of it.
What the engineer finds
Measured causes behind the recommendations, prioritised by impact.
61% cache hit rate: two in five visitors wait 1.8s instead of 40ms.
One non-cacheable block makes category pages bypass Varnish.
One plugin adds 340ms to every category render, invisible to a page-speed tool.
Checkout and live ERP calls are missing from the Lighthouse score.
Two cron groups stuck for eleven days explain the late order exports.
Product imagery gains 0.2s, so it goes last in the plan.
What we need
Read-only throughout. Measurement is rate-limited so it never affects your store.
Search Console and analytics
Field vitals, traffic and device mix, revenue modelling
SSH
Configuration, service versions, profiling
Database
Slow query log, index behaviour, dataset size
Magento admin
Cache, indexer, cron and extension configuration
Application monitoring
Transaction traces, slow queries, background jobs, history
Varnish and cache layer
Hit rates, VCL, invalidation behaviour
Scope and what it costs
Catalog size, template count, hosting model and whether peak testing is included decide the effort.
Scoped on the first call
Catalog size, templates, hosting model and whether peak testing is included.
Fixed price before work begins
Under our Fixed Cost Estimate Guarantee, the approved number is what you pay.
Remediation quoted separately
Phased, so quick wins ship before the structural work starts.
Independent by design
The report is yours to act on with anyone. The don't-bother list is proof of that.
When to run one
You don't need to know where the seconds go. You need a reason to want them measured.
- Pages feel slow and nobody can say why
- Core Web Vitals are failing and rankings are drifting
- Peak season is coming and last year hurt
- A previous optimization delivered less than promised
- You're weighing a Hyvä migration and want the numbers
- Your admin has become painful for the team
What a performance audit should give you, and rarely does
Anyone can send you a score. The work is attributing each second to a cause, including on the pages Core Web Vitals never looks at.
What you get
Magebit audit
Typical agency
Automated tool
Uncached journeys measured
Cart, checkout, logged-in browsing, admin
Sometimes
Every second attributed to a cause
Function, query or job, not an opportunity list
Varies
Cache HIT and MISS reported separately
Background work checked
Cron, indexers and queue consumers
Sometimes
Field data, not just a lab run
Varies
Partial
Expected seconds against each fix
Fixed by the team that measured it
Sometimes
What partners say about us
Appreciate everyone’s hard work and effort in moving us forward!
Alex Brynou
Director of Systems Architecture
Within just two to three months, they resolved issues that previously seemed unresolvable.
Tim Johnson
CTO
There is no challenge for which they can't find a solution.
Will Aubuchon
CEO
What I value most is consistency. Magebit knows our store inside out, responds fast, and keeps it running smoothly year after year.
Marian Gaidoš
CEO
Why ambitious brands choose Magebit
#1 Adobe Commerce partner worldwide
The top-ranked Adobe Commerce agency on the planet by Adobe themselves.
55+ Hyvä Certificates
The most certified Hyvä agency in the world. Confirmed by Hyvä themselves, twice.
Award-winning solutions
Innovator, World Traveler, and eCommerce Excellence awards across Meet Magento NYC and HIVE London, and more.
Hyvä Platinum Partner
The most-certified Hyvä agency worldwide and the first Hyvä Platinum Partner in the USA. 55+ certified developers and 40+ projects delivered.
ISO certified
ISO 9001 & 27001 for quality and security.
Findings correlated across evidence
Profiler, code, database and cache counters read together, so the report names one cause rather than four symptoms.
Baymard certified design team
UX grounded in large-scale ecommerce research.
Magebit team at Meet Magento, #1 Adobe Commerce agency worldwide
The world’s leading Magento agency
By certified developers, Magebit holds the number-one spot among Adobe Commerce agencies worldwide, and we’re the most certified Hyvä agency on the planet. Proof that the depth is real, not a logo on a page.
#1 Adobe agency worldwide
200+ Adobe certifications
Most certified Hyvä agency
Adobe Subject Matter Expert
Learn more
Every slow store is losing money on schedule
Merchants come to us with a PageSpeed screenshot and leave with a conversion story. Show me your store and I'll show you where the seconds go, what each one costs, and the exact plan to take them back.
Reviewed by Kristaps Rjabovs
Co-founder of Magebit, Forbes 30 Under 30
Frequently asked questions
If you can't find the answer you're looking for, feel free to reach out to us. We're here to help.
We guarantee process, not a number, and anyone promising a specific score before seeing your store is selling a template. The audit establishes your realistic ceiling on the current theme, what tuning gets you there, and what a rebuild would add. Our production track record, 95+ PageSpeed and 90+ field vitals at global scale, is public and verifiable.
Scoped on the first call against catalog size, templates and whether peak testing is included, then quoted as a fixed price before anything starts. Remediation is quoted separately once findings show what's actually needed.
Only when the numbers say so, and the report shows what tuning can still buy on your current theme so you can compare. Plenty of stores get where they need to be without a rebuild, and we'd rather tell you that than sell the bigger project.
That's one of the most common reasons to commission this audit. Core Web Vitals only measure anonymous visitors on cacheable pages, so a store can pass them while checkout takes four seconds, logged-in browsing crawls and cron has been stuck for a fortnight. We profile the uncached journeys, the background work and the admin as standard.
Where peak readiness is the concern, yes, by agreement and at a time you choose. Steady-state numbers don't predict Black Friday, and pretending otherwise is how stores get surprised in November.
Yes, an anonymised sample on request. You should know what you're buying before you buy it.
None. Measurement and profiling are read-only and rate-limited. Remediation only happens if you commission it separately.
Show us your slowest page
Your store, your numbers, your worst offender. You'll get field and lab data, a cause behind every second, and a straight answer on your theme's ceiling.
- 1
A certified engineer replies
Not a sales script.
- 2
Seconds attributed, not listed
With hours and value against each.
- 3
No obligation
The findings are yours to keep.