Magento performance benchmark — realistic 2026 ranges
Honest 2026 Core Web Vitals ranges for a typical Magento 2 store across Luma, Hyvä, Mage-OS Breeze and PWA Studio — with the methodology, the caveats, and the things that quietly blow these numbers up in production.
Magento 2 performance benchmarks — realistic 2026 ranges
A Magento performance benchmark is a set of measurable speed and stability values (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, First Contentful Paint, Time to First Byte, total JavaScript bytes and main-thread time) that a typical Magento 2 storefront produces on a defined hardware and network baseline. This page publishes the ranges I see in audits on real stores in 2026, broken down by theme stack — Magento Open Source 2.4.9 with Luma, with Hyvä, with Mage-OS Breeze, and with PWA Studio.
I publish these because every other "Magento benchmark" article on the web is either (a) a synthetic lab number on an unrealistically tuned demo store, or (b) a single anecdotal data point from one client. Neither is useful when you are trying to budget a performance project or set targets for an internal team. The ranges below are what I see across the audits I run — they are honest about what is measurable and honest about where the variance comes from.
If you want to see how these ranges play out on actual stores, I have written up three anonymised projects on the Magento optimization case studies page, and the underlying recipe is in the LCP / INP / CLS recipe.
Methodology — how these numbers were derived
Sample. 30+ Magento 2 audits I performed between 2024 and 2026, plus a smaller set of demo-store benchmarks I ran on freshly provisioned environments. Stores range from ~500 SKUs (small DTC) to ~80,000 SKUs (enterprise B2B). About 70% are on Magento Open Source, 30% on Adobe Commerce.
Test method. Mobile traces via Lighthouse 12 (Chrome DevTools) with "Mobile" preset (Slow 4G, 4x CPU throttling). Field data via Chrome User Experience Report (CrUX) over the trailing 28 days. Server timing from Magento's built-in `MAGE_PROFILER=html` and from `New Relic APM` where the client had it installed. INP captured both in lab via Total Blocking Time as a proxy and in field via CrUX INP.
What the "typical store" baseline is. ~2,000–5,000 SKUs, 1–2 storefronts, ~20–35 installed extensions, single-tenant VPS at 8 vCPU / 16GB RAM with Varnish + Redis + MariaDB on the same host, Cloudflare in front, PHP 8.3, OPcache + APCu enabled, FPM with `pm = dynamic` at sensible values. This is the median Magento environment I see in audits.
What I cannot measure. I do not have access to a uniform multi-tenant testbed, so absolute values vary by hosting. The ranges below assume sensible hosting; a VPS half this spec will produce worse numbers and a bare-metal box twice this spec will produce better ones. Conversion lift is not benchmarked here — that is on the case-studies page.
Baseline: vanilla Magento 2.4.9 + Luma
Vanilla Magento Open Source 2.4.9 with the Luma theme on the typical-store baseline is the starting point. Luma ships ~41 RequireJS modules that the browser has to parse before the page becomes interactive, four Knockout.js view models on the homepage, jQuery, jQuery UI, the Magento UI library and the X-Magento-Init bootstrap. The mobile main-thread cost is ~5–7 seconds even on a clean install with no third-party modules. With 20–35 typical extensions installed, that climbs further.
| Metric | Mobile range | Desktop range | Vital target | Verdict |
|---|---|---|---|---|
| LCP | ~4.2 – 5.8s | ~1.8 – 2.6s | ≤ 2.5s | Mobile fails |
| INP | ~310 – 520ms | ~150 – 230ms | ≤ 200ms | Mobile fails |
| CLS | ~0.15 – 0.30 | ~0.05 – 0.15 | ≤ 0.1 | Mobile usually fails |
| FCP | ~2.4 – 3.6s | ~0.9 – 1.4s | ≤ 1.8s | Mobile fails |
| TTFB | ~310 – 720ms (Varnish hit) | ~280 – 620ms | ≤ 800ms | Usually OK |
| JS transferred | ~1.4 – 2.2 MB | same | — | Heavy |
| Lighthouse Perf | ~25 – 45 | ~70 – 88 | ≥ 90 | Mobile fails |
Hyvä baseline numbers
Hyvä replaces the Knockout + RequireJS frontend with Alpine.js and Tailwind CSS — no RequireJS, no jQuery, ~10x less JavaScript shipped to the browser. On the same hardware and store profile, Hyvä typically takes a Lighthouse mobile score from the 30s into the 80s without any other change. It is the single biggest performance lever available on Magento 2 today, and I cover the migration sequence in the Luma → Hyvä migration playbook.
| Metric | Mobile range | Desktop range | Vital target | Verdict |
|---|---|---|---|---|
| LCP | ~1.9 – 2.6s | ~0.9 – 1.5s | ≤ 2.5s | Usually passes |
| INP | ~110 – 220ms | ~60 – 130ms | ≤ 200ms | Usually passes |
| CLS | ~0.02 – 0.08 | ~0.01 – 0.05 | ≤ 0.1 | Passes |
| FCP | ~1.1 – 1.8s | ~0.5 – 0.9s | ≤ 1.8s | Passes |
| TTFB | ~280 – 620ms | ~250 – 580ms | ≤ 800ms | Same as Luma |
| JS transferred | ~120 – 280 KB | same | — | Lean |
| Lighthouse Perf | ~78 – 95 | ~92 – 99 | ≥ 90 | Passes |
Note: the Hyvä numbers assume the migration was done correctly. A botched Hyvä install with leftover Luma JS, an unconverted third-party module loading Knockout, or an injected analytics tag with heavy main-thread work can pull these numbers back toward Luma's range. The DTC case on the case studies page is exactly this pattern.
Mage-OS Breeze baseline numbers
Mage-OS Breeze (the community fork's theme initiative) sits between Luma and Hyvä in performance. It keeps a familiar developer workflow closer to Luma but ships less JavaScript and uses a leaner bootstrap. The trade-off is that the ecosystem of compatible modules is smaller than Hyvä's, so on real stores you often end up with a mixed-bag fix-list.
| Metric | Mobile range | Desktop range | Vital target | Verdict |
|---|---|---|---|---|
| LCP | ~2.4 – 3.2s | ~1.2 – 1.8s | ≤ 2.5s | Borderline |
| INP | ~180 – 280ms | ~80 – 160ms | ≤ 200ms | Borderline |
| CLS | ~0.05 – 0.12 | ~0.02 – 0.08 | ≤ 0.1 | Borderline |
| FCP | ~1.6 – 2.3s | ~0.7 – 1.2s | ≤ 1.8s | Borderline |
| TTFB | ~280 – 620ms | ~250 – 580ms | ≤ 800ms | OK |
| JS transferred | ~340 – 680 KB | same | — | Mid |
| Lighthouse Perf | ~58 – 78 | ~85 – 95 | ≥ 90 | Mobile borderline |
PWA Studio baseline numbers
Adobe's PWA Studio (Venia) decouples the storefront from Magento via GraphQL and ships a React + Apollo single-page app. The first paint is slower than Luma because of the React bootstrap, but warm/subsequent navigation is the fastest of the four — because the app does not re-fetch the shell. PWA Studio is the right answer when product / category page interactivity matters and your team is staffed for a React codebase. I cover the trade-off in detail on the Hyvä vs PWA Studio page.
| Metric | Mobile cold | Mobile warm nav | Vital target | Verdict |
|---|---|---|---|---|
| LCP | ~3.0 – 4.5s | ~0.8 – 1.4s | ≤ 2.5s | Cold fails, warm passes |
| INP | ~140 – 240ms | ~80 – 160ms | ≤ 200ms | Mostly passes |
| CLS | ~0.04 – 0.10 | ~0.01 – 0.04 | ≤ 0.1 | Passes |
| FCP | ~1.8 – 2.6s | ~0.4 – 0.8s | ≤ 1.8s | Cold borderline |
| TTFB | ~180 – 410ms (GraphQL CDN) | same | ≤ 800ms | OK |
| JS transferred | ~480 – 980 KB | ~30 – 90 KB | — | Heavy cold, light warm |
| Lighthouse Perf | ~55 – 78 | ~88 – 96 | ≥ 90 | Cold fails, warm passes |
What blows benchmarks up in production
None of the ranges above survive contact with a real production environment unchanged. The single biggest variance source on every Magento store I have audited is third-party JavaScript — Google Tag Manager firing 30+ tags, an "AB testing" platform that inlines blocking JS in the head, a popup / email-capture vendor that loads a 240KB bundle, a chat widget that pulls in three webfonts of its own. Strip those, and the numbers in the matrices above are achievable. Leave them in, and even Hyvä can fail Core Web Vitals.
The second biggest source is webfont configuration. A site loading six webfont weights with font-display: block can add 800–1400ms to LCP on its own. Drop to two weights with font-display: swap and a system-font fallback, and the LCP recovers immediately. The third source is unreserved layout slots — sticky headers, announcement bars, lazy-loaded hero images, third-party iframes — all of which inflate CLS regardless of theme choice.
The fourth source is the backend. A Magento store with a slow `catalog_product_index_price` rebuild, a Redis instance thrashing on eviction, an `Update by Schedule` indexer that has been stuck for 24h, or a Varnish VCL leaking ESI holes will produce slow TTFB no matter which theme you ship. The B2B case on the case studies page is exactly this pattern.
How to measure your own store
The minimum measurement kit: Lighthouse mobile via Chrome DevTools (run three times, take the median); PageSpeed Insights for the CrUX field data over the trailing 28 days; the Search Console Core Web Vitals report for population-level data; New Relic or Magento's built-in profiler for server-side timing; a slow-query log over 24 hours; and a tag inventory from the network panel. That is enough to classify whether your bottleneck is frontend JS, third-party JS, webfonts, layout shift, server time or database.
If you want a written report instead of running the audit yourself, my Core Web Vitals tune-up service does exactly that — Lighthouse traces, server-timing breakdown, prioritised fix list, fixed-fee $499. The report alone is often enough for an internal team to act on, and about a third of audit clients use it that way.
Frequently asked questions
What's a good Lighthouse score for a Magento store in 2026?
Mobile 90+ is achievable on Hyvä with disciplined third-party JS management. Mobile 75+ is realistic on Mage-OS Breeze. Mobile 60+ is realistic on tuned Luma. Anything below 50 on mobile means there is an obvious win on the table — usually third-party JS or webfont configuration.
Are Core Web Vitals thresholds changing in 2026?
The three core metrics (LCP, INP, CLS) and their thresholds are unchanged in 2026. INP replaced FID as a Core Web Vital in March 2024; the threshold is ≤ 200ms for "Good". Google has not announced a fourth Core Web Vital for 2026 — though TTFB, FCP and TBT are still measured as supplementary metrics.
Is Hyvä always faster than Luma?
In raw frontend-JS terms, yes — Hyvä ships roughly 10x less JavaScript than Luma. But "faster store" is a different question. If your bottleneck is TTFB, database joins, or third-party tags, Hyvä alone will not move the number. See the B2B case on the case studies page.
Should I move to Mage-OS Breeze instead of Hyvä?
Mage-OS Breeze is fine if your team prefers a Luma-like authoring workflow and you can live with a smaller compatible-module ecosystem. Hyvä is the safer commercial bet — wider module compatibility, larger Marketplace, more partners. The performance gap between them is real but smaller than the gap between either of them and Luma.
How accurate are Lighthouse lab scores vs CrUX field data?
Lighthouse is a deterministic lab measurement on a synthetic device profile; CrUX is real-user data over a 28-day window from Chrome users who opted in. They almost never agree perfectly. CrUX is the source of truth for Google ranking purposes. Use Lighthouse for fast iteration during development and CrUX to confirm the population-level shift after deploy.
Do these numbers include third-party tag impact?
The matrix ranges assume a "median" third-party load — Google Analytics, Meta Pixel, one chat widget. They do not assume an "extreme" load (30+ GTM tags, AB-test platforms, video pixels). With an extreme third-party load, all four theme stacks will fail Core Web Vitals.
What hosting do you recommend?
For a typical store: single-tenant VPS at 8 vCPU / 16GB RAM with NVMe storage, Varnish + Redis + MariaDB co-located, Cloudflare in front, PHP 8.3 with OPcache + APCu. Adobe Commerce on Cloud has its own constraints. Shared hosting is not viable for Magento 2 — you will not hit the TTFB targets above.
How often should I re-benchmark?
Monthly Lighthouse + CrUX pull is enough for stable stores. Re-benchmark immediately after any deploy that touches the theme, head tags, third-party tags, FPC config, or the indexer. The number you care about is the trend over time, not the single-day reading.
Can you guarantee a specific Lighthouse score?
No, and any developer who guarantees a Lighthouse score is lying. I will commit to Core Web Vitals targets (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1) in writing when the scope is right. Lighthouse scores fluctuate run-to-run and depend on factors outside any single developer's control (network, third-party vendors, Chrome version updates).
Want to know where your store sits in these ranges? Fixed-fee from $499 audit · $2,499 sprint · ~Nh @ $25/hr.
Benchmark my store