Hyvä vs. Luma, measured

Every Magento performance conversation eventually arrives at the same question: is the frontend the problem, and is Hyvä the answer? The honest answer to both is usually yes. It is still worth verifying on your own store rather than taking it on trust from us or from anyone selling you a rebuild. This post explains what’s structurally different between the two frontends and how to measure the gap before you spend money on it.

Why Luma is slow by design

Luma, the stock Magento frontend, is slow because of decisions baked into the platform around 2015:

• RequireJS loads JavaScript as a dependency waterfall. The browser discovers what to fetch next only after executing what it already fetched. On a high-latency mobile connection, that’s round-trip after round-trip before the page becomes interactive.
• Multiple heavy JS layers ship at once. jQuery, KnockoutJS, and Magento’s Knockout-based UI-component layer all arrive on every page, whether the page uses them or not.
• Layout XML renders more than the page needs. Blocks nobody sees still get built, and third-party extensions attach their scripts globally rather than where they’re needed.

None of this appears in a profiler as one slow line, but it does appear as megabytes of JavaScript and a main thread that stays busy for seconds on the mid-range phones your customers use.

What Hyvä actually changes

Hyvä is a replacement theme. It removes the Luma frontend stack entirely: no RequireJS, no jQuery, no Knockout. Templates are server-rendered PHP with Alpine.js for interactivity and Tailwind for styles. In our own measurements the JavaScript payload typically drops from somewhere north of a megabyte to well under a hundred kilobytes, something you can verify for yourself in any browser’s network tab on the demo store.

The trade-off: every extension that touches the frontend needs a Hyvä-compatible module or a rewrite. The compatibility ecosystem is mature for popular extensions and often nonexistent for older bespoke modules. The extension audit is where most of a Hyvä project’s cost sits.

Checkout is a separate decision. A stock Hyvä install keeps the Luma checkout, through Hyvä’s Luma theme fallback; Hyvä Checkout is a separate product (Hyvä’s documentation, checked July 22, 2026). Checkout is often the page with the largest impact on conversion.

How to measure it yourself

Don’t compare your production store against a Hyvä demo; that conflates theme, catalog, hosting, and third-party scripts. A fair comparison looks like this:

1. Get your baseline from field data, not just Lighthouse. CrUX (via PageSpeed Insights) shows what real visitors experienced over 28 days: LCP, INP, CLS. An unthrottled lab run on a fast developer machine can look far better than what real visitors on mid-range phones get.
2. Separate frontend from backend. TTFB is dominated by the backend and network (server, DNS, TLS); if TTFB is 1.5 s, a new theme won’t fix it. Most of what happens after TTFB is what a frontend swap can address; a slow backend or network still needs its own fix.
3. Stage the comparison honestly. Same server, same catalog, same extensions enabled, third-party tags either on in both or off in both. Run Lighthouse several times and compare medians; single runs are noise.
4. Track the business metric alongside. Record conversion by device class before and after, and judge the project on that rather than on a Lighthouse score.

When the answer isn’t Hyvä

Hyvä is our default recommendation for Luma stores with a performance problem, but not for every store. A store with 4-second TTFB has a backend problem. A store that’s already on PWA Studio faces a different set of trade-offs. And a store about to replatform shouldn’t invest in either; that’s a replatform-or-fix question first.

If you want the measurement done for you, with the frontend/backend split, the extension audit, and the fix list in priority order, that’s exactly what our performance audit is. It’s also how most of our Magento work starts.