Why Hyvä Performance Beats Luma — The Real Reasons 2026
Hyvä performance is not magic — it is the removal of Luma’s JavaScript weight. Here is what actually makes Hyvä fast, what it does not fix, and how to decide if it is worth the rebuild.
Hyvä performance is the headline reason the theme has taken over new Magento front-end projects — but the why is widely misunderstood. Hyvä is not a caching plugin or an optimisation layer bolted onto Luma; it is a complete front-end replacement that removes the JavaScript stack causing Luma’s performance problems in the first place. Understanding what actually drives Hyvä performance tells you both why it is fast and, just as importantly, what it does not solve. This guide gives the honest engineering picture.
Search intent: informational/decisional — Magento developers and merchants evaluating Hyvä for performance. We cover the JavaScript architecture behind Hyvä’s speed, which Core Web Vitals it improves, what it does not fix, and how to judge whether the migration is worth it. It builds on our Hyvä vs Luma comparison, Core Web Vitals guide and Hyvä developer guide.
Hyvä Performance: It Is the JavaScript, Not Magic
The core of Hyvä performance is a single architectural decision: throw out Luma’s JavaScript stack. Luma ships RequireJS as a module loader, jQuery for DOM manipulation, and Knockout.js for its UI components — a substantial payload that loads, parses and executes on every page. That JavaScript is the primary reason Luma stores struggle with interactivity metrics on mid-range mobile devices.
Hyvä replaces all of it with Alpine.js, a tiny reactive framework, and Tailwind CSS with unused classes purged at build time. The result is a JavaScript baseline a fraction of Luma’s — Hyvä targets a very small footprint by default. This is the whole secret of Hyvä performance: there is simply far less JavaScript for the browser to download, parse and run. It is not that Hyvä optimises the heavy stack better; it removes it. That distinction matters, because it explains why no amount of Luma tuning reaches the same place.
Hyvä Performance: Which Core Web Vitals It Improves
The Hyvä performance advantage lands most decisively on one metric: INP (Interaction to Next Paint). INP measures how quickly a page responds to user interaction, and it is punished by main-thread congestion — exactly what Luma’s JavaScript execution causes. Because Hyvä ships so little JavaScript (per the Hyvä project), the main thread is free to respond to taps and clicks quickly, and INP that was stubborn on Luma often becomes green almost by default on Hyvä. As we covered in our Core Web Vitals guide, INP is the metric Luma stores find hardest, which makes this the headline Hyvä performance benefit.
LCP (Largest Contentful Paint) also improves, though less exclusively. Hyvä’s server-rendered HTML and lean CSS mean the page paints without waiting on a heavy JavaScript bundle, so content appears sooner. CLS (Cumulative Layout Shift) benefits from cleaner, more predictable markup, though CLS was always the most fixable metric on Luma too. The pattern is clear: Hyvä performance gains are largest exactly where Luma is weakest, which is why it is such an effective answer to a Core Web Vitals problem.
| Metric | Luma difficulty | Hyvä performance impact |
|---|---|---|
| INP | Hardest — JS-bound | Largest gain, often green by default |
| LCP | Moderate | Improved via server render + lean CSS |
| CLS | Most fixable on Luma | Improved via cleaner markup |
| Total JS weight | Heavy (RequireJS + jQuery) | A fraction of Luma’s baseline |
Hyvä Performance: What It Does Not Fix
This is where honesty about Hyvä performance matters, because it is frequently oversold. Hyvä is a front-end replacement. It does nothing for your backend. If your Varnish is misconfigured, your Redis is undersized, your database is slow or your server response time is poor, Hyvä will not save you — a fast front end still has to wait for slow HTML to arrive.
Concretely, Hyvä performance does not improve TTFB (time to first byte), which is a server and caching concern; it does not speed up the admin, which is unaffected by the storefront theme; and it does not fix slow catalogue search or checkout logic, which live in the backend. The correct mental model is that Hyvä fixes the front-end layer of performance — the JavaScript and rendering cost — while backend performance work (the subject of most of this Magento performance series) remains entirely necessary. A store needs both. Treating Hyvä as a substitute for backend tuning is the most common mistake we see in Hyvä performance expectations.
Hyvä plus a slow backend is still slow. The best Hyvä performance results come from pairing the lean front end with a properly tuned backend — Varnish, Redis, a healthy database and fast server response. Hyvä removes the front-end ceiling; it does not raise the backend floor. Budget for both, or you will migrate and wonder why the store still feels sluggish under load.
Hyvä Performance: Is the Migration Worth It?
Given a genuine Hyvä performance advantage, the real question is cost. Migrating to Hyvä is a front-end rebuild, not a configuration change — your theme, your custom components and any third-party extensions with storefront UI all need Hyvä-compatible equivalents or rework. That is real effort and real budget, and it is the honest counterweight to the performance benefit.
The decision comes down to a few questions. Are you failing Core Web Vitals — particularly INP — and has Luma tuning hit its ceiling? Are you planning a redesign anyway, making the rebuild cost partly sunk? Do your key extensions have Hyvä compatibility, or is the ecosystem work manageable? If you are fighting a losing battle with INP on Luma and have a redesign on the horizon, Hyvä performance makes a strong case. If your store performs adequately and a rebuild would be purely for marginal gains, the calculus is weaker. Our Hyvä migration checklist covers the practical scoping, and our Magento team plans and executes Hyvä migrations. The right answer is a business decision informed by honest engineering, not a default.
How we frame Hyvä performance for clients
We explain it as removal, not optimisation. Clients often expect Hyvä to be a faster version of Luma. It is not — it is a different front end that does not carry Luma’s JavaScript weight. Framing it as “we remove the thing that was slow” rather than “we make the slow thing faster” sets accurate expectations and explains why Luma tuning could never get there.
We are explicit that Hyvä does not touch the backend. The disappointment we most want to avoid is a client migrating for speed and finding the store still slow because the real bottleneck was Varnish or the database. We assess backend and front end together, and we say plainly when Hyvä is not the fix for their particular problem.
The extension ecosystem drives the real cost. The theme rebuild is predictable; the variable is third-party extensions with storefront UI that need Hyvä-compatible versions or rework. We audit the extension list early, because it is what turns a Hyvä migration from a clean project into a complicated one.
Frequently Asked Questions About Hyvä Performance
Why is Hyvä so much faster than Luma?
Because it removes Luma’s JavaScript stack rather than optimising it. Luma ships RequireJS, jQuery and Knockout, which load and execute on every page. Hyvä replaces them with Alpine.js and Tailwind, shipping a fraction of the JavaScript. Less to download, parse and execute means a faster, more responsive page — especially on mobile.
Which Core Web Vitals does Hyvä improve most?
INP (Interaction to Next Paint) sees the largest gain, because it is punished by the main-thread congestion Luma’s JavaScript causes and Hyvä ships far less. LCP improves via server-rendered HTML and lean CSS, and CLS via cleaner markup. The biggest wins are exactly where Luma is weakest.
Does Hyvä fix backend performance?
No. Hyvä is a front-end replacement and does nothing for the backend. It does not improve TTFB, speed up the admin, or fix slow catalogue search and checkout logic. If Varnish, Redis, the database or server response are slow, Hyvä will not help — a lean front end still waits for slow HTML to arrive.
Is migrating to Hyvä worth it?
It depends on your situation. If you are failing Core Web Vitals — especially INP — and Luma tuning has hit its ceiling, and ideally you are planning a redesign anyway, Hyvä makes a strong case. If your store performs adequately, a full front-end rebuild purely for marginal gains is harder to justify. It is a business decision.
How much work is a Hyvä migration?
It is a front-end rebuild, not a configuration change. Your theme and custom storefront components need rebuilding in Hyvä, and any third-party extensions with storefront UI need Hyvä-compatible versions or rework. The theme work is predictable; the extension ecosystem is the variable that determines whether it is a clean project or a complex one.
Can I get Luma as fast as Hyvä with tuning?
Not fully, because the limit is architectural. You can improve Luma meaningfully — bundling, deferring, removing unused modules — but RequireJS and jQuery remain, so there is a JavaScript floor you cannot get below. Hyvä is fast because it does not have that stack at all. Tuning narrows the gap; it does not close it.
Weighing Up a Hyvä Migration?
Our team assesses front end and backend together, scopes the extension work, and executes Hyvä migrations.
