Hyvä for Magento 2
Hyvä theme development for a Magento store that loads fast
Hyvä replaces Magento’s default Luma front end with one built on Tailwind CSS and Alpine.js. Pages carry far less JavaScript, and the storefront becomes much simpler to change. We build new Hyvä storefronts and move existing Luma stores across.
The basics
What Hyvä is, and what it replaces
Hyvä is a front end for Magento 2. It does not change the admin, the catalogue, the database or your back-end modules. It replaces the part your customers see.
Magento’s default theme, Luma, is built on RequireJS, Knockout and jQuery, with styles compiled from LESS. It loads a large amount of JavaScript on every page before anything becomes interactive, and it takes specialist knowledge to change safely.
Hyvä removes that stack. It keeps Magento’s layout XML and PHP templates, which Magento developers already know, and uses two small libraries in place of the old ones: Tailwind CSS for styling and Alpine.js for interactive behaviour.
Hyvä is made by a separate company, not by Adobe, and its licence model has changed over time. Check current Hyvä licensing before budgeting. We will go through it with you during discovery.
Why merchants move
Why Hyvä is faster and simpler
-
Far less JavaScript
A Luma page loads many JavaScript modules through RequireJS before it responds to a tap. A Hyvä page loads Alpine.js and the small scripts that page needs. Less code means quicker pages, most noticeably on mobile.
-
Core Web Vitals within reach
With Luma, good Core Web Vitals take sustained optimisation work. With Hyvä the starting point is already light, so effort goes into your images, fonts and third-party tags rather than fighting the theme.
-
Simpler to develop
Styling is done with Tailwind utility classes in the template, and the stylesheet contains only the classes in use. Changes take fewer files and are easier to review.
-
Easier to hand over
Tailwind and Alpine.js are widely used outside Magento. A developer new to your store can be useful sooner than with Luma’s UI component system.
Side by side
Luma vs Hyvä: the practical differences
| Luma | Hyvä | |
|---|---|---|
| JavaScript | RequireJS, Knockout, jQuery and UI components | Alpine.js and small page-specific scripts |
| Styling | LESS, compiled from a large theme library | Tailwind CSS, only the classes in use are shipped |
| Page weight | Heavy by default, needs bundling and tuning | Light by default |
| Core Web Vitals | Achievable with ongoing optimisation | Much easier to reach and to keep |
| Extensions | Most work as shipped, because they are written for Luma | Front-end parts need a compatibility module |
| Checkout | Knockout-based Magento checkout | Hyvä Checkout, or the Luma checkout kept as a fallback |
| Licence | Included with Magento | Check current Hyvä licensing |
Luma is not broken, and a well-tuned Luma store can perform acceptably. The difference is how much work it takes to get there and stay there.
Compatibility
Extensions and checkout: check each one
This is where Hyvä projects succeed or overrun. Back-end extensions are unaffected. Any extension that adds something to the storefront was written for Luma’s JavaScript, so its front end will not run on Hyvä without a compatibility module.
Compatibility modules exist for a great many popular extensions, published by Hyvä, by extension vendors and by the community. Many is not all, so we check every installed extension before quoting.
-
Compatible already
A maintained compatibility module exists. We install it, style it and test it.
-
No module available
We write the compatibility layer, replace the extension with a compatible alternative, or question whether it is still needed.
-
Hyvä Checkout
A separate Hyvä product that replaces the Knockout checkout. Each payment and shipping method needs its own Hyvä Checkout integration, so we confirm yours first.
-
Keeping the Luma checkout
A Hyvä storefront can leave the existing checkout on Luma. It is a sensible first phase when the checkout is heavily customised.
The rebuild
What a Luma to Hyvä rebuild involves, step by step
A move to Hyvä is a front-end rebuild, not a theme switch. Templates are rewritten, not converted.
-
01
Extensions and custom front-end code
We list every extension and custom feature with a storefront part, and record whether a compatibility module exists or needs writing.
- Compatibility report
- Fixed scope and price
-
02
Keep the design or refresh it
The existing design can be carried over closely, or refreshed. Either way, page templates are agreed before code is written.
- Agreed page designs
-
03
Rebuild the page types
A Hyvä child theme is set up, then the header, navigation, category, product, search, cart, account and content pages are rebuilt in Tailwind and Alpine.js.
- Hyvä child theme
- Staging site
-
04
Extensions and checkout
Compatibility modules are installed or written. The checkout moves to Hyvä Checkout or stays on Luma, as agreed. CMS content is checked page by page.
- Working extensions
- Tested checkout
-
05
Measure and regression test
Every customer journey is tested on real devices, analytics and tracking are verified, and Core Web Vitals are compared with the figures recorded before work began.
- Test report
- Before and after measurements
-
06
Switch over
The new theme goes live in a planned release. The Luma theme stays in the codebase, so switching back is a configuration change if anything unexpected appears.
- Launch runbook
- Rollback path
A straight answer
When not to move to Hyvä
Hyvä is our default for new Magento builds and the right move for most Luma stores. It is not right for all of them, and a rebuild is a real cost. If one of these describes your store, we will say so.
Ask whether Hyvä suits your store-
The slowness is on the server
A theme cannot fix slow database queries, missing caching or undersized hosting. Those need performance work first.
-
Key extensions have no Hyvä support
If the store depends on several complex front-end extensions with no compatibility module, the cost of writing them can outweigh the gain.
-
You are about to change platform
There is little sense in rebuilding a front end that will be retired within the year.
-
The store already meets its targets
If your Luma store passes Core Web Vitals and converts well, the budget may do more good elsewhere.
Questions
Hyvä questions, answered plainly
What is Hyvä for Magento 2?
Hyvä is a front-end theme for Magento 2 that replaces the default Luma theme. It removes Luma’s RequireJS, Knockout and jQuery stack and uses Tailwind CSS and Alpine.js instead. The result is far less JavaScript on each page, faster loading and a storefront that is simpler for developers to work on.
Is Hyvä faster than Luma?
In almost every case, yes. A Hyvä page sends much less JavaScript and CSS to the browser than the same page on Luma, so it renders and responds sooner, particularly on mobile. How much faster depends on the store, its images, its third-party scripts and its hosting, so we measure before and after.
Do Magento extensions work with Hyvä?
Back-end extensions work with Hyvä unchanged. Extensions that add features to the storefront need a Hyvä compatibility module, because their front-end code was written for Luma. Compatibility modules exist for many popular extensions, but not all, so every extension on a store should be checked before a Hyvä project is priced.
Is Hyvä free?
Hyvä’s licence model has changed over time, and the theme, Hyvä Checkout and other Hyvä products are licensed separately. Check current Hyvä licensing on the Hyvä website before budgeting. Development time is a separate cost: a move from Luma is a front-end rebuild, quoted as a fixed price after an audit.
What is Hyvä Checkout?
Hyvä Checkout is a separate product from the Hyvä theme. It replaces Magento’s Knockout-based checkout with a lighter one that is easier to customise. Payment and shipping methods each need a Hyvä Checkout integration, so the methods a store uses should be confirmed as supported before choosing it.
How long does a Luma to Hyvä migration take?
It depends on the number of page templates, the amount of custom front-end functionality and how many extensions need a compatibility module written. A store close to standard Magento is a far shorter project than one with a customised checkout and many storefront extensions. We set the schedule after the compatibility audit.