Luma to Hyvä: What You Actually Gain, and What It Costs

Luma was designed around 2015 assumptions: RequireJS module loading, Knockout for anything interactive, jQuery underneath all of it, LESS on top. It works. It has also been the single biggest reason Magento stores score badly on Core Web Vitals, and no amount of minification changes that — you cannot tune your way out of a stack that ships a megabyte of JavaScript before the shopper has done anything.

Hyvä replaces that layer with Tailwind CSS and Alpine.js and deletes most of the rest. The performance results are genuinely dramatic, which is why the migration gets recommended so freely. What gets mentioned less often is that you are rebuilding your entire storefront, paying a license fee to do it, and inheriting a compatibility problem with every extension you own.

Both halves are true. Here's the honest version of each.

What Hyvä actually replaces

It helps to be precise about the scope, because "switching themes" undersells it and "replatforming" oversells it.

Hyvä is a Magento theme plus a set of modules. It runs on the same Magento backend, the same PHP layer, the same database, the same admin. Your catalog, orders, customers, indexers, cron jobs, integrations, and ERP connection are untouched. In that sense it is far less risky than moving to Shopware or Medusa.

What it removes is the entire client-side stack:

That last row is the one that decides your project size. The templates are still PHTML, so the mental model is familiar — but every template you have customized in Luma is written against a stack that no longer exists. There is no automated conversion, and there shouldn't be. You are rewriting the storefront.

The gains, specifically

JavaScript payload. This is the headline and it deserves it. A stock Luma category page typically ships somewhere north of a megabyte of JavaScript across a long tail of requests. A Hyvä equivalent is usually under 100 KB total, often well under. That difference shows up in every metric that matters and on every page of the site at once.

LCP and INP. Less JavaScript means less main-thread work, which means the browser paints sooner and responds to taps sooner. INP in particular tends to improve more than teams expect, because Luma's interaction cost is spread across dozens of Knockout bindings that all initialize before the page settles. Hyvä stores routinely sit in the green on lab tests where the Luma version was orange.

Fewer requests, simpler waterfall. RequireJS resolves dependencies at runtime, which produces a request waterfall that is genuinely hard to optimize because it is dynamic. Removing it removes an entire class of performance problem rather than tuning it.

Development speed. This is the gain teams report most enthusiastically after the fact, and it is underrated in the business case. Debugging a Knockout binding through the UI component JSON layout tree is a specialist skill that takes months to build. Debugging Alpine is reading the HTML. Frontend changes that took two days in Luma often take two hours.

Hiring. Tailwind and Alpine are mainstream web skills. Knockout and RequireJS are not, and the pool of developers who know them well is shrinking every year. You are trading a niche dependency for a common one.

A cleaner baseline for everything else. Once the frontend is thin, the remaining performance work — PDP gallery and LCP, category page collection bloat — is easier to see and easier to fix, because it is no longer buried under JavaScript execution time.

The drawbacks nobody puts in the pitch deck

It is a rebuild, not a reskin. Budget accordingly. For a mid-size store with a moderately customized Luma theme, a Hyvä build is typically a multi-month project, not a sprint. Anyone quoting you two weeks is either describing a stock Hyvä install with your logo on it or has not looked at your codebase.

Your Luma customizations do not come with you. Every custom template, every layout XML override targeting a Luma block, every LESS file, every Knockout component your last agency wrote — none of it ports. In practice this is often healthy: a lot of accumulated Luma customization exists to work around Luma. But it is work you are paying for twice.

The extension tax. This is the one that derails timelines. Any third-party module that renders frontend markup or ships JavaScript needs a Hyvä-compatible version. There are three outcomes per extension:

• The vendor or the Hyvä community maintains a compatibility module. Best case, and increasingly common for popular extensions — but check the version, not just the name.
• The vendor has nothing, and you rebuild the frontend of that extension yourself.
• The extension is fundamentally a Luma widget with a backend attached, and the honest answer is to replace it.

Audit this before you commit to a date. A store with forty extensions can easily find that six of them account for half the project.

Checkout is a separate decision and a separate cost. By default, Hyvä leaves the Magento checkout in place — which means the heaviest, most JavaScript-dependent page on your site keeps running the old stack behind a Hyvä-styled shell. If checkout performance is part of your business case, you need a dedicated Hyvä checkout, and those are separately licensed products with their own compatibility requirements around payment and shipping modules. Read our breakdown of Magento checkout performance before assuming the theme migration fixes it.

It costs money, and it is not open source. Hyvä is commercially licensed — a one-time fee per domain for the theme, with separate licensing for checkout and the UI component library. Check their current pricing directly rather than trusting a number in a blog post, and factor in that it is a source-available license, not an open one. If "everything in our stack must be freely redistributable" is a hard constraint for you, this is where the conversation ends.

Page Builder and the marketing workflow. Page Builder content works with Hyvä through a compatibility layer, but any content your team built that leans on Luma widgets or slider JavaScript needs checking. Find out early whether your marketing team's existing pages survive, because discovering it at launch is expensive.

One more upstream to track. You now follow Hyvä releases alongside Magento releases and patch levels. That is a modest ongoing cost, but it is not zero, and it compounds with the patch discipline you already owe Magento.

Hyvä will not fix a slow backend

This is the most common disappointment, and it is entirely predictable.

Hyvä is a frontend change. It makes the browser's job dramatically easier. It does nothing about TTFB, and TTFB is a backend number — Varnish hit rate, Redis configuration, PHP version, OpenSearch, database indexes, a slow ERP call blocking a page render.

If your uncached pages take 2.5 seconds to produce HTML, they will still take 2.5 seconds to produce HTML after the migration. The shopper will see a faster paint once that HTML arrives, which is real value, but the "our site got 4x faster" story you were sold will not materialize.

Run the diagnosis first. If your TTFB is bad, work through the site-wide performance foundations before or alongside the frontend rebuild — not after.

Who should move, and who shouldn't

Strong case for Hyvä:

• Your Core Web Vitals are failing in field data and the profiling points at JavaScript execution and main-thread blocking rather than server time.
• You were already planning a redesign. The marginal cost of doing it in Hyvä instead of Luma is small, and it is by far the cheapest moment to switch.
• Your frontend team is slow because of Luma, and you can put a number on that.
• Mobile is a meaningful share of your revenue and your mobile scores are poor.

Weak case, at least for now:

• Your storefront works, your Vitals pass, and you have no redesign planned. There are higher-return places to spend the budget.
• You have a heavily customized Luma theme, a long extension list, and no appetite for a rebuild. Wait for a natural redesign cycle.
• Your real problem is server-side. Fix that first; the answer may be that you never needed the theme migration.
• You are seriously evaluating leaving Magento altogether. Don't invest in a frontend rebuild for a platform you may exit — settle that question first.

Running the project without surprises

The sequence that avoids most of the pain:

1. Audit extensions before you scope anything. List every module that touches the frontend, classify each as compatible / needs work / replace, and get that in front of whoever signs off on the budget. This single step is the difference between an accurate estimate and a bad one.
2. Baseline your current numbers. Field data from CrUX, not one lab run. You will want to prove the gain afterward, and lab-only comparisons are too noisy to argue with.
3. Decide checkout early. Stock Magento checkout under Hyvä, or a dedicated Hyvä checkout, with the licensing and payment-module implications that follow. This shapes the timeline more than any other single choice.
4. Rebuild rather than port. Teams that try to recreate their Luma theme pixel-for-pixel in Hyvä spend most of their budget reproducing decisions nobody remembers making. Treat it as a redesign with a known content structure.
5. Use a store view or a staging domain to run both. You can run Hyvä on one store view while Luma serves another, which makes phased rollout and comparison realistic rather than theoretical.
6. Guard the gains. A Hyvä store with four tag manager containers, a chat widget, and a personalization script is a slow store again. The thin frontend is an asset you have to actively protect after launch.

The honest summary

Hyvä is the best answer available for Magento storefront performance, and the developer experience improvement is real enough that teams who have made the move rarely want to go back.

It is also a full storefront rebuild with a license fee, an extension audit, a separate checkout decision, and no effect whatsoever on your server response time. That is a good trade for plenty of stores. It is a poor use of budget for a store whose Vitals already pass, and it is the wrong first move for a store whose problem is a 2-second TTFB.

Decide which of those you are before you decide about Hyvä.

Emyrix does Magento frontend and performance work for merchants and agencies — including the extension audit and honest scoping that decides whether a Hyvä migration is worth it for you. If you're weighing the move, let's talk.