Hyvä for Magento: when a frontend rewrite pays off
Moving from Luma to Hyvä is not a reskin. It is a rewrite of the presentation layer along with the modules attached to it. When it pays off, what it actually costs, and when we advise against it.
The conversation usually starts the same way. The store works and it sells, but it feels slow, and someone has proposed rewriting the frontend on Hyvä. The question is whether that is really necessary, or whether there is still something left to squeeze out of what is already there.
This article does not explain what Hyvä is or why it is faster. We covered that separately, together with an assessment of the other alternatives for the Magento frontend, in Our way to efficient Magento 2 frontend. What follows is about the decision: when the rewrite pays off, what it really costs, and when we say no.
Luma is not abandoned. It is frozen
The most common argument in this discussion is that Luma runs on outdated libraries. Stated that way it does not hold up, and it is easy to refute. Here is where things stood on 29 August 2026:
| Library | Version in Magento | Latest release |
|---|---|---|
| jQuery | 3.7.1 | current stable 3.x line |
| Knockout | 3.5.3 | 25 March 2026 |
| RequireJS | 2.3.8 | 30 November 2025 |
None of those repositories is archived, and each received a patch within the last year. Anyone calling this dead software is not describing reality.
The real problem only shows up in the gaps between releases. Knockout has been on the 3.5.x line since February 2019, and six years and four months passed between 3.5.1 in November 2019 and 3.5.2 in March 2026 with no release at all. RequireJS has been on 2.3.x since 2017, and almost six years passed between 2.3.6 in 2018 and 2.3.7 in 2024. Both libraries are alive enough to get an occasional fix, and neither is moving forward by design.
This is not a complaint about their authors. It describes the position a store is in: loading AMD modules in the browser and Knockout’s MVVM bindings are solutions from before ES modules and modern bundlers. They work. Nobody starts a new project on them.
And here is the argument that carries the most weight in practice and comes up least often, because it is not technical. It is getting harder to find a frontend developer who wants to work in RequireJS and Knockout. It gets harder every year, and that feeds straight into the time and cost of every future change to the store. Hyvä puts Tailwind CSS and Alpine.js on the other side of that scale, tools a candidate already knows before the interview starts.
One caveat: the jQuery version depends on the Magento version a given store runs. The table above describes the current development branch, not a store four upgrades behind.
When optimising Luma stops paying off
A frontend rewrite is not the first step and should not be. Before anyone quotes a migration, it is worth exhausting the cheaper work, because very often that is where most of the gain is:
- images in modern formats, with dimensions and lazy loading,
- server-side caching and a CDN,
- server response time, meaning TTFB,
- third-party scripts, of which a typical store carries a dozen or more, each one somebody’s decision rather than a fault.
If the store is still slow after those four, it is worth measuring where the time actually goes. The line falls in one place: as long as the bottleneck is assets and the server, rewriting the theme fixes nothing. Only when the problem becomes how much code the browser has to execute before the page responds does changing the presentation layer become the right answer, because that layer is the cause.
Let us say it plainly, because it saves misunderstandings at the quoting stage: if your problem is TTFB, Hyvä will not solve it.
The biggest cost is not the theme, it is the modules
This is where most budgets in this kind of project go missing, and it is the question worth asking before any figure is named.
Hyvä does not render Luma templates. It is not a layer on top of the existing theme, it is a separate presentation layer. Every module with a frontend of its own, so filters, search, configurators, loyalty programmes, marketplace integrations, needs either a Hyvä-compatible version or a rewrite.
That is why the cost of a migration is a function of the extension list, not of catalogue size or page count. Two stores with similar traffic can differ severalfold if one has five modules with ready support and the other has twenty, three of them written to order years ago. A serious quote starts by reviewing that list, not by counting templates.
The good news is that the ecosystem has matured: many vendors now publish Hyvä-compatible versions, and compatibility modules exist for a share of the popular extensions. The bad news is that this applies to popular extensions. Something written for one specific store five years ago has to be rewritten, and nobody will do that for us.
Hyvä Checkout is a second decision, not part of the first
Worth knowing before it enters a quote as a given: the checkout is a separate product with a separate scope of work. You can move to Hyvä and keep your current checkout.
If it does go in, though, that is the place where the change touches conversion directly rather than through speed. In the store described below, the checkout shipped together with the theme, and it shows decisions that have nothing to do with the framework: buying without creating an account, with the account offered only after the order is placed, an order summary visible throughout, and a specific delivery date range instead of a vague “3–5 business days”.
That is the right way to think about this stage. Hyvä Checkout gives you a faster and simpler flow, but what stands inside it remains the store’s decision.
What it looks like in production
Sprint Rowery moved from Luma to Hyvä together with Hyvä Checkout. Below is field data from the Chrome UX Report, meaning measurements from real users over a 28-day window rather than a single lab test. Read on 29 August 2026:
| Metric | Mobile | Desktop | “Good” threshold |
|---|---|---|---|
| LCP | 1.4 s | 1.1 s | under 2.5 s |
| INP | 179 ms | 78 ms | under 200 ms |
| CLS | 0.06 | 0.1 | under 0.1 |
| FCP | 0.7 s | 0.5 s | under 1.8 s |
| TTFB | 0.4 s | 0.3 s | under 0.8 s |
Core Web Vitals assessment: passed, on both device types. A Magento store with a mobile LCP of 1.4 seconds is not what the platform delivers by default. Anyone can verify this in PageSpeed Insights by entering the store’s address.
Two things have to be said honestly, or the table above misleads.
We are not quoting the pre-migration figures in this article. Read the numbers above as a description of a state rather than as a measure of change.
One metric sits exactly on the threshold. Desktop CLS is 0.1, and the distribution shows that a share of sessions crosses it. We point this out deliberately, because something more important than the number follows from it: layout shifts are not a property of the framework. They come from what the page loads and in what order, for instance a banner above the header or a widget injected by a third-party script. No theme cleans that up on anyone’s behalf.
The second store we run on Hyvä is Trefl. We are not quoting metrics for it, because the optimisation work there is not finished, and showing an unfinished result next to a finished one would imply a comparison we are not making.
When not to do it
Four situations in which we advise against a migration, even though we could carry one out:
- A store facing a replatform. If changing platform is on the table within a year, rewriting the Magento frontend is an investment in something that will be thrown away regardless.
- A heavy extension set with no Hyvä support. Once most of the critical modules need rewriting, the cost stops matching the benefit and project risk grows faster than the budget.
- A bottleneck on the server side. High TTFB, slow queries, missing caching. That is different work and it has to happen first, whatever the theme.
- No capacity on the store’s side. A migration is not only code. Somebody has to test the checkout, review the categories and sign off on changes. If there is nobody, the deadline slips anyway.
In short
Rewriting the frontend on Hyvä pays off when the cheaper optimisations are already spent, the bottleneck is code execution in the browser, and the extension list does not turn the project into rewriting the whole store. Then the effect is measurable and it lasts, and the store leaves behind a technology it is getting harder to hire for.
If you want to know which side of that line your store is on, start with a review of the module list and a measurement of where the time actually goes. We handle Magento implementations and development as well as support and upgrades for existing stores.