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, but you shouldn’t take that 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 on your own shop 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 cold 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 shows up as a single slow line in a profiler. It shows up as megabytes of JavaScript and a main thread that’s busy for seconds on mid-range phones, which is where your customers are.

What Hyvä actually changes

Hyvä is a replacement theme, not a patch. 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: stock Hyvä keeps the Luma checkout unless you adopt Hyvä Checkout or a headless one, and checkout is often the page with the largest impact on conversion.

How to measure it yourself

Don’t compare your production shop 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. Conversion by device class, before and after, is the number that justifies the project.

When the answer isn’t Hyvä

Hyvä is our default recommendation for Luma shops with a performance problem, but not for every shop. A shop with 4-second TTFB has a backend problem. A shop that’s already on PWA Studio faces a different set of trade-offs. And a shop 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.