Hyvä vs Luma: is rebuilding your Magento front end worth it?

For a Magento 2 store that will stay on the platform for the next few years, rebuilding the front end on Hyvä is usually worth it. It removes the main reason Magento storefronts are slow in the browser and slow to change. It is not worth it if you are about to replatform, if the store depends on front-end extensions that have no Hyvä support, or if your Luma storefront already passes Core Web Vitals and rarely changes.

The rest of this article explains the difference, the honest costs and how to tell which of those situations you are in.

What Luma is, and why it is heavy

Luma is the storefront theme that ships with Magento 2. Most Magento stores run it or a theme built on top of it. Its front-end stack was chosen when Magento 2 was designed, and it has many layers:

• RequireJS loads JavaScript as a large number of separate modules.
• Knockout drives the dynamic parts of the page, such as the mini cart and the checkout.
• jQuery and jQuery UI provide the widgets behind menus, tabs, galleries and forms.
• LESS stylesheets are compiled from many files, inherited across modules and themes.
• UI components are configured in XML and assembled in the browser.

The result is a lot of JavaScript and CSS files, and a lot of code that runs on every page whether the page needs it or not. Bundling and minification reduce the number of requests, but the browser still has to parse and execute the code. On a mid-range phone that shows up as a page that looks ready before it responds.

It is heavy for developers too. One small change can touch layout XML, a PHTML template, a Knockout template, a JavaScript mixin and a LESS file. That is why front-end work on Luma takes longer than merchants expect.

What Hyvä replaces it with

Hyvä is a replacement front-end theme for Magento 2. It keeps the server side of Magento’s rendering: layout XML, blocks and PHTML templates. It is not a headless build. There is no separate front-end application to host and no API layer between the storefront and Magento.

What changes is everything that runs in the browser:

• Tailwind CSS replaces LESS. Styles are written as utility classes in the templates, and the build produces a single small stylesheet containing only the classes in use.
• Alpine.js replaces Knockout and jQuery. It is a small library, and the behaviour is written in the template beside the markup it controls.
• RequireJS is removed. Pages make far fewer requests and load far less JavaScript.

The Magento admin, the catalogue, orders, pricing rules and back-end integrations are untouched. Hyvä changes the storefront only.

The honest benefits

Performance

With much less JavaScript to download and run, pages become usable sooner and respond faster to taps and clicks. That helps the Core Web Vitals that Luma stores most often struggle with, particularly on mobile.

It does not fix everything. A slow server, a full-page cache that keeps missing, oversized images and a tag manager full of third-party scripts will still be slow on Hyvä. Those are covered by performance optimisation work, and they are worth fixing first because they are cheaper.

Developer speed

A change that crossed five files on Luma is usually made in one template on Hyvä. Front-end tasks take less time, which lowers the cost of every change you make after the rebuild. For a store that changes often, this is the benefit that pays back the project.

Simpler templates

Markup, styling and behaviour sit together and can be read from top to bottom. Tailwind and Alpine.js are widely used outside Magento, so a capable front-end developer becomes productive quickly without first learning Knockout and RequireJS.

The honest costs

• It is a front-end rebuild. A Luma theme cannot be converted. Every template you have customised is built again, whether you keep the current design or take the chance to refresh it.
• Extensions need compatibility modules. Any extension that outputs something on the storefront was written for Luma’s JavaScript. To work on Hyvä it needs a compatibility module. Many widely used extensions already have one, from the vendor or from the Hyvä community. For the rest, one has to be written. Extensions that only work in the admin or the back end are not affected.
• Custom front-end features are rewritten. Product configurators, custom calculators and anything else built on Knockout or jQuery widgets need a new implementation.
• The team has a learning curve. Developers used to Luma need time with Tailwind, Alpine.js and Hyvä’s conventions, including a build step for the stylesheet.
• Tracking has to be checked. Analytics and marketing tags often hook into Luma’s JavaScript. Each one needs to be reimplemented or verified.
• Licensing needs checking. Hyvä’s licensing has changed over time and differs between its products. Check Hyvä’s own website for the current terms for the theme, the checkout and Adobe Commerce support before you budget. Do not rely on an older article, including this one.

Hyvä and Luma compared

How to decide

Rebuild now if

• You expect to stay on Magento for the next few years.
• The store still fails Core Web Vitals on mobile after caching, images and third-party tags have been dealt with.
• A redesign is already planned. The front-end work is happening anyway, so do it once on the better foundation.
• Front-end changes are slow and expensive enough to hold back trading plans.
• Most of your storefront extensions already have Hyvä compatibility.

Wait if

• There are more urgent problems: an unsupported Magento version, missing security patches or unstable hosting. Fix those first.
• An extension the business relies on has no compatibility module and no clear route to one.
• Your peak trading period is close. Launch well before it or after it.

Stay on Luma if

• You plan to move off Magento in the near future.
• The storefront already passes Core Web Vitals in field data and is seldom changed.
• The store depends on so much Luma-specific customisation that rebuilding it would cost more than it returns.

What the project looks like

1. Audit. List every customised template, custom front-end feature and storefront extension, and check the compatibility position of each.
2. Design decision. Rebuild the existing design as it is, or redesign. The first is quicker and easier to compare.
3. Build. Create a child theme of the Hyvä default theme and rebuild page type by page type: header and navigation, category, product, cart, customer account and content pages.
4. Compatibility. Install the modules that exist and write the ones that do not.
5. Checkout. Choose between the two routes described below.
6. Tracking and third parties. Reimplement and verify analytics, consent and marketing tags.
7. Test. Functional testing across devices, accessibility checks and a performance comparison with the old theme.
8. Launch. Magento assigns themes per store view, so a multi-store installation can move one store at a time. Keep the old theme in place until the new one has proved itself.

Hyvä Checkout, or the Luma checkout as a fallback

The checkout is a separate decision from the rest of the storefront, and there are two common routes.

Keep the Luma checkout as a fallback. Hyvä provides a fallback mechanism that serves chosen routes, typically the checkout, with a Luma-based theme while the rest of the store runs on Hyvä. Your existing payment and shipping integrations carry on working as they do today. The price is that the checkout stays as heavy as it was, and you maintain a second, Luma-based theme styled to match.

Move to Hyvä Checkout. This is a separate product built for the Hyvä stack, without Knockout. It is lighter and easier to customise. Every payment method and every checkout customisation has to be supported on it, so check with your payment provider before committing.

A sensible low-risk plan is to launch the storefront with the fallback checkout and move the checkout as a second phase. If your payment methods are already supported, doing both at once avoids maintaining two front-end stacks. Either way, the checkout takes the money, so it gets the most testing.

What to do next

Make the list that decides most of this: every extension and custom feature that shows something on your storefront. Against each one, note whether a Hyvä compatibility module exists. A short list with good coverage means a contained project. A long list with gaps tells you where the cost is.

Then look at your Core Web Vitals in Search Console, and at how much front-end work you expect over the next two years. Poor field data together with a busy roadmap makes the case for a rebuild. Good field data and a quiet roadmap makes the case for leaving Luma alone. Our Hyvä theme development page describes how we scope and deliver the rebuild.