---
title: "Hyvä vs. Luma, measured"
description: "What actually makes Luma slow, what Hyvä changes, and how to measure the difference on your own catalog instead of relying on vendor claims."
author: "Luboš Zápotočný"
published: "2026-05-21"
language: "en"
canonical: "https://zapolu.com/blog/hyva-vs-luma/"
---

# 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ä](https://hyva.io) 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](https://alpinejs.dev)
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](/blog/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](/services/performance-audit/)
is. It's also how most of our [Magento work](/services/magento/)
starts.