Introduction

If you hadn’t guessed from the name, Hyvä Themes is a new way to build out storefronts (themes) for Magento 2. Its primary focus is on speed/performance, though there are other benefits too, and we’ll cover these later on.

The purpose of this article is to try and provide a subjective view of Hyvä Themes, including the benefits it brings as well as the considerations that need to be made to help merchants, who might be considering it as an option for their Magento 2 store, to make an informed decision.

But first, we need to talk about the existing, default Magento 2 frontend (theme).

In case you were wondering, Hyvä means ‘Good’ in Finnish.

Hyvä Themes Logo

What is Luma?

Magento’s standard frontend is known as ‘Luma’, as this is the name of Magento’s demo storefront as well as the reference theme that powers it. We’ll refer to it by this name throughout this article. It’s fair to say Luma based themes are not particularly fast, and they’ve had their fair share of criticism directed towards them ever since Magento 2 launched. However, this has been increasing over the past couple of years as site performance has become increasingly important due to the increase of site visitors coming from mobile devices.

Luma based themes perform poorly (and score poorly in page speed reports, especially on mobile) due to the architecture and bloat of both the CSS and (more so) the JavaScript included*. The way JavaScript is loaded causes pages to take longer to become both visible and interactive, and the size and number of JavaScript and CSS files included on the page is excessive. This is further compounded when you consider so much of the content is ‘dead code’ (i.e. code that never runs and therefore not required).

*CSS (Cascading Style Sheets) are used to apply design, the theme (i.e. the look and feel) to a website. JavaScript is used on almost every website to provide dynamic/interactive content. This includes anything from menus, accordions and tabs to carousels/sliders, maps and more.

Luma Theme Homepage

So how does Hyvä differ?

Hyvä Themes aim to resolve the performance issues by essentially removing all the output introduced by Luma based themes and starting afresh with a blank canvas. The hundreds of individual JavaScript files and bloated libraries are replaced with one single JavaScript framework, Alpine.js, that allows simple dynamic interactions to achieved with minimal code/effort. In addition, all CSS is removed in favour of using Tailwind CSS, a framework that can reduce CSS output by over 90% compared to traditional methods.

This results in an incredibly lean, and therefore fast, storefront experience, even on underpowered mobile devices with low signal (i.e. slow internet speed).

Hyvä Themes Homepage

The Benefits of Hyvä Themes

So we’ve highlighted the key focus on speed, but let’s look further at why you’d want to use Hyvä Themes? Or more importantly, why should you choose it over default Magento (or any other option)?

  • Performance
  • Maintenance
  • Time to market (speed of development)
  • Developer experience
  • Developer availability
  • New and existing storefronts welcome

Performance

As we touched on at the outset, the obvious benefit is that Luma based themes are slow and bloated due to their architecture and overuse of external libraries for JavaScript and CSS output, which Hyvä Themes resolves by removing and reimplementing them.

We’ve already touched on why Hyvä Themes are faster, technically, but let’s compare the two using Google’s Page Speed Insights tool. This isn’t an in-depth analysis across different pages with multiple test runs; we’ll simply perform a ‘one shot’ test on a product detail page (PDP) using the same product.

Product Detail Page (PDP) - Desktop

Luma Demo Desktop Page Speed Score
Hyvä Demo Desktop Page Speed Score

Notes:

  • Firstly, yes, I had too many tabs open when taking these screenshots!
  • The URL of the Luma theme has been redacted as a popular extension vendors demo store was utilised to run these tests and any criticism of Luma is not fair to be associated with them
  • This again highlights these are not exact/scientific tests due to different infrastructure being used (i.e. each site is hosted on a different server)
  • However, we’re more focused on client-side (browser) performance with these tests (i.e. performance of the frontend assets, rather than the server)

Hyvä Themes is the winner here, with better scores, but you might be thinking that Luma isn’t that bad, and perhaps this isn’t worth the effort? This is a fair assumption, but these are desktop scores; we’ll compare mobile next. But first, it’s worth noting that the Luma theme, whilst not too far behind, is ~5 seconds slower in terms of page load (see the Speed Index, which measures how long it takes the contents of the page to become visible).

In addition, 2 of 3 key metrics on Google’s new Core Web Vitals are not meeting the recommended scores.

Largest Contentful Paint (LCP), the measure of the time at which the most significant part of the visible screen is rendered (i.e. becomes visible), is taking 1.5 seconds*, which is just over the target threshold.

*Note: LCP is usually deemed ‘good’ (i.e. passing) under 2.5 seconds, but on desktop specifically, this score is flagged as ‘Needs Improvement’.

Cumulative Layout Shift (CLS), the measure of how much the elements on the page move (shift) whilst being rendered (loaded), is also failing, scoring 0.335, which is flagged as ‘Poor’ when the target to pass (’Good’) is 0.1 or below.

First Input Delay (FID), which measures the initial interactivity and responsiveness of a site, you may notice is absent from the above results. This is because it is not measurable directly with this type of test*; however, its correlating metric, Total Blocking Time (TBT), is measured, with both Luma and Hyvä coming under the desired 300ms.

*If you want to understand why see this overview of lab vs field data.

Luma scores better here. Why? Because it loads less content (such as JavaScript files) upfront, whereas Hyvä is loading all its JavaScript and CSS at the outset (but bear in mind this is two small files). Because of these architecture decisions, Luma still has content to load after this metric, whereas Hyvä is already finished. This additional content loading correlates to the next important metric, Time to Interactive (TTI).

TTI measures the time it takes for the site to become fully interactive so that user input can be reliably processed (i.e. the site responds correctly to what the user does, e.g. clicking a button). As we can see from the scores above, both sites perform well, but Luma is taking an additional 300ms over Hyvä, which far outweighs the 10ms deficit Hyvä had on the Total Blocking Time (TBT). This, in turn, contributes to the overall inferior Speed Index score seen on Luma.

Product Detail Page (PDP) - Mobile

Luma Demo Mobile Page Speed Score
Hyvä Demo Mobile Page Speed Score

From the mobile results, it’s clear there is a much more significant performance gap. As soon as we’re on a slower connection (e.g. using 3G/4G), Luma really starts to struggle. The Speed Index is now up to ~13 seconds (from ~5 on desktop), whilst Hyvä is still only at 1 second (from 0.3). Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are also impacted further on Luma, whilst Hyvä is still meeting the required scores to pass Core Web Vitals.

Total Blocking Time (TBT) is still winning out on Luma (but only by 20ms) for the same reasons outlined above, but Time to Interactive (TTI),  which was not a major issue on desktop, is now a colossal ~25 seconds (versus 1.5 on Hyvä). This means users are waiting nearly half a minute whilst on their phones to interact with the page fully!

To sum up, Luma’s architectural decisions considerably impact storefront performance, especially on mobile devices/connections, which become unacceptable by today’s standards. Hyvä, on the other hand, is offering blazing fast speeds across all devices.

Can ‘Luma’ based themes not just be made faster?

So we’ve seen that Hyvä is much faster ‘out of the box’, but surely there’s room to make improvements with a Luma based theme to get the same speed? The answer is both ‘yes’ and ‘no’.

‘No’, in that Luma is slow because of the framework it is built on and the JavaScript and CSS technologies used. The number of bloated libraries included means that page load times (and especially ‘time to interactive’) are slower. Whilst some optimisations can be made, these will only have a minor impact compared to Hyvä. Without replacing the framework itself, major gains cannot be made.

Which brings us to the ‘yes’ – replacing the frontend framework is the answer to reducing the bloat and improving the page speed, which is precisely what Hyvä Themes does. It’s just at this point we cease to call it a ‘Luma based’ theme!

Maintenance

How can using a theme that removes all of Magento’s default frontend output and completely replaces it with its own implementation be easier to maintain, you might wonder?

Upgrades

Firstly, let’s consider Magento’s quarterly security/enhancement upgrades, which often include changes to the storefront itself. We’re likely to find far less disruption to a Hyvä based theme than Luma one because of the removal of all the default storefront output Hyvä performs. Due to this, any changes to templates (the files that contain the HTML markup), JavaScript and CSS files in the default Magento codebase in an upgrade won’t impact a Hyvä based theme.

Of course, we have upgrades to the Hyvä Theme itself to consider, but these upgrades can be managed at your own pace and are rarely impacted by the changes to the frontend introduced by Magento’s upgrades.

Components

Hyvä takes a component-based approach, which means each part* of the theme is managed within one file that includes all the markup (HTML), styles (CSS) as well as any dynamic functionality (JavaScript).

*Such as the mini cart, image gallery or any other self-contained aspect of the page

Whereas with a Luma based theme, each of those elements (HTML/CSS/JavaScript) are managed in discrete files with little or no correlation to one another. Using components means it’s easy to upgrade or swap out parts of the storefront without impacting anything elsewhere, reducing the time needed to maintain the theme.

Managing optimisations

As we noted earlier, some optimisations can be made to Luma based themes to improve the performance above the baseline outlined in the speed tests above. The main optimisation that has had the most traction in the past few years is known as JavaScript bundling*.

*Note: this should not be confused will Magento’s inbuilt JavaScript bundling configuration setting that generally decreases the default storefront performance further.

JavaScript bundling involves using an external tool* that combines (or bundles, hence the name) all the default JavaScript files together into just a few files to remove all the individual JavaScript requests on page load and reduce the load time (and increase page speed).

*Such as Magepack or baler.

However, as alluded to above, whilst this improves the speed of a Luma based theme, it still comes nowhere close to the performance Hyvä based themes can offer, especially on mobile devices/connections. Furthermore, introducing a bundling tool adds a further layer of complexity and introduces another layer to the codebase that needs to be maintained.

Sadly, bundling is not a one-time implementation. Every time code changes are made that impact JavaScript in any way (e.g. installing new/upgrading existing modules, adding/modify JavaScript functionality or upgrading Magento), the bundling tool needs to be re-run. Whilst much of this can be automated (with further upfront development investment), any errors picked up during the bundling process need to be managed before deploying code changes.

The point being made here is that the level of effort to keep a Luma based theme even somewhat performant is much greater than a Hyvä one. This, along with the two other points made above, means the same applies to the total cost of ownership (TCO) of a Luma based theme over a Hyvä one.

Time to market

Because Hyvä Themes contain less bloat and introduce clean, dedicated components for each area of frontend output, developers spend less time battling the inner workings of indirectly related code to achieve the modifications they need to make. In doing so, they can also be more confident the changes they make won’t impact elsewhere.

In addition, working with Alpine.js and Tailwind CSS, for most developers, has so far proven to be a much quicker experience compared to the frameworks utilised in Luma, given the reduced bloat and the endless libraries of code that need to be traversed and understood to make (for the majority of the time) relatively simple changes with Magento’s standard theme.

In other words, the simplicity of the architecture of Hyvä Themes means it’s much easier for developers to learn, understand and work with. This extends to debugging issues, too, given the reduced frontend code and files to traverse through. To be fair and unbiased, this metric needs more time to be definitively proven (i.e. more builds on Hyvä Themes need to be undertaken to gather further feedback). However, the early signs and feedback from developers and agencies working with the platform are very encouraging.

Developer experience

Why should you care if a developer enjoys working on your site? How does that impact your revenue? Whilst it may not be something a merchant should care about, it is worth taking notice of, as a good developer experience breeds a larger community of developers, which tends to foster greater collaboration and knowledge sharing.

This is to your benefit because a healthy, growing and supportive community means developers supporting your site have access to a group of like-minded individuals to ‘bounce ideas off’ and get help. This generally means solutions to problems that may arise when developing for your site are easier to come by, and the overall quality level of the output increases.

The end result is a more performant/stable site for you! At the time of writing, there are now almost 600 developers/Hyvä enthusiasts on the community Slack channel with frequent discussion and knowledge sharing taking place and many more joining all the time. For a platform that was only announced 6 months ago, that’s pretty impressive!

Developer availability

Whilst Hyvä Themes has a different technology stack for implementing JavaScript and CSS, everything else about working with Magento 2 stays the same. Hyvä is both fresh yet familiar for Magento developers and, therefore, relatively simple to get used to. In addition, the barrier to entry for those new to working with Magento 2’s frontend is much lower than the skills needed for Luma based themes.

Unlike other new frontend options, such as PWAs (Progressive Web Apps), which we’ll cover later on, working with Hyvä Themes means agencies can continue to utilise the same development team they always have, rather than having to rely on recruiting or re-training developers to learn completely different technologies. And whilst expertise is available for these other technologies, there is generally a lack of Magento experience/understanding for those strong in these areas.

The improved developer experience and growing community outlined above is only likely to enhance the situation further by ensuring a healthy supply of skilled developers available to support your site (whether directly or via an agency) now and into the future.

New and existing storefronts welcome

Hyvä Themes does not require you to start with a fresh (new) install of Magento 2. If you have an existing Magento 2 site, you can simply* replace the current theme and save time, not having to recreate all the backend/admin panel functionality (or external integrations) you may already have in place. If not, starting a new project on Magento 2, whether migrating from Magento 1 (or elsewhere), does not impact your ability to utilise Hyvä Themes.

*It’s a little more involved than that, as we’ll outline in the considerations below, but the key point is that either a new or an existing Magento install is a perfectly suitable place to start implementing your Hyvä Themes project on.

Finally, to ensure absolute clarity, Hyvä Themes is available for Magento 2 only, i.e. Magento 1 is not supported!

Considerations

We’ve talked a lot about the benefits of using Hyvä Themes, but surely there must be some downsides? That’s a fair comment, so we’ll now outline the considerations that need to be made before selecting Hyvä Themes as an approach.

  • System requirements / Browser support
  • Third-party module compatibility
  • Checkout
  • Commerce / B2B
  • Licence
  • PWA

System requirements / Browser support

Magento version compatibility

We’ll keep this one short and sweet: Hyvä Themes requires Magento 2.4 or greater. So if you’re on 2.3 or earlier, you’ll need to ensure you upgrade either before or during your transition to Hyvä Themes.

Outside of this, the system requirements for a Magento 2 store running Hyvä Themes are identical to that of any other Magento site.

Internet Explorer support

Internet Explorer 11 (IE11) is the bane of developers lives, and whilst it’s always getting ever closer to the point of being no longer supported by Microsoft, it never seems soon enough!

However, with Microsoft announcing their sites (e.g. the web versions of Office, Outlook, Teams etc.) will be dropping support for IE11 from this summer, the end finally feels in sight. Magento themselves also no longer officially support IE11, and Hyvä Themes is no different.

However, the key difference is that whilst Magento doesn’t officially support IE11 anymore, there is very little that doesn’t work or can’t be made to work when using a Luma based theme due to the JavaScript utilised being much less modern.

Hyvä, on the other hand, uses modern JavaScript that improves developer experience, maintainability and time to market, but means trying to add IE11 support is practically infeasible*.

* It’s not impossible, but it would require substantial time to implement the necessary modifications and then there is the additional ongoing maintenance to consider.

For most merchants, losing IE11 support will have a negligible impact* and is far outweighed by the benefits of the performance Hyvä Themes brings and the reduced cost from a development perspective by not having to support an antiquated browser. However, for others (especially those whose customer base are forced to use outdated hardware, such as those in the public sector/government), IE11 support may still be necessary. This, therefore, may be deciding factor as to whether Hyvä Themes is the right choice.

*Since the turn of the year (2021), the global usage of IE11 has dropped under 1% and is reducing further each month, and as of March 2021, that value is now 0.73%. See more information on browser market share here.

Third-party module compatibility

Almost every Magento site utilises modules (or extensions) from third-party vendors, whether free or paid. When it comes to using Hyvä Themes, some additional work is often required to ensure the module works functionality and looks good. However, it should be noted this is only in relation to storefront (theme) output, i.e. all backend code, external integrations and admin panel related output are not affected.

As you may have already guessed, what is affected is the storefront JavaScript and CSS output, which will need to be rewritten to support Hyvä Themes way of doing things (i.e. Alpine.js and Tailwind CSS). This may sound like a substantial undertaking, but it depends on the amount of code that needs replacing/converting.

With a Luma based theme, this is less of a problem in that the CSS and JavaScript that ships with a module are supported ‘out tof the box’. However, this is not as clear cut as it might seem, especially from a CSS perspective. From our experience at Fisheye, which I’m sure will be similar for most others, the styles that ship with a module are never usable without at least some level of work to bring them in line with the existing theme used on the site.

At Fisheye, we almost always disregard existing styles and implement our own because building on the existing styles is often more time consuming*. This again supports Hyvä Themes decision to start from a simple, non-bloated base and build/maintain a lean site with minimal complexity and layers of overrides.

*For transparency, we have utilised the popular SASS based theme from Snowdog in almost all of our previous work on Luma based themes at Fisheye, which means using the default CSS (LESS) shipped with modules was never viable in the first place.

Therefore, that essentially leaves us with the problem that any JavaScript written for a third-party module is not useable in a Hyvä based project without being reimplemented. Again the only way to measure this effort is to review the amount of storefront JavaScript included within the modules that we wish to use, which then becomes a consideration between the developer/agency and the merchant regarding whether the additional investment is justified.

It’s worth noting at this point, not all modules even ship with storefront JavaScript, or even CSS, depending on their purpose. We’ve already undertaken an audit of the common third-party modules we utilise at Fisheye to review what we’ll need to reimplement, and whilst some modules will need a decent amount of work to replace the JavaScript, the overall effort is not that great.

In addition, moving back to the plus points of developer experience and availability and the community forming around it, many third-party extensions have already been made compatible with Hyvä Themes. Better yet, these compatibility modules are being shared within the community (i.e. free of charge). At the time of writing, some well-used extensions in the Magento ecosystem have already been made fully/partially compatible, such as Smile’s popular Elasticsuite search and layered navigation solution and Yireo’s versatile Google Tag Manager module.

Checkout

How does Hyvä Themes affect the checkout? The short answer is, it doesn’t. Hyvä Themes doesn’t make any specific opinion over the checkout and essentially leaves the end choice up to you (or the developer). Both the standard checkout (i.e. the one utilised with Luma based themes) and Hyvä’s own optional checkout solution are available.

Utilising the ‘Luma checkout’ is achieved by a simple fallback module, provided by Hyvä Themes, which allows the standard Luma JavaScript and CSS to be supported purely for the checkout only*. This is not a downside compared to Luma (as it’s the same), but it does mean developers need to also retain knowledge on (or learn about) working with Luma’s JavaScript and CSS technologies to modify and maintain the checkout, in addition to learning Hyvä’s new approaches used across the rest of the storefront.

*The mini cart and main cart page itself have been reimplemented in Hyvä and are not part of the checkout fallback.

If you don’t fancy this, Hyvä’s checkout solution may be more suited to you. This a React based* solution with, as you’d expect, a focus on speed and developer experience. Whilst it’s a solid solution, it currently has limited support for most payment gateways (at least those commonly used in the UK), but it certainly has the potential to become the de-facto option on Hyvä based projects in future.

*React is a popular, modern JavaScript framework created by Facebook.

You can essentially ‘bring your own’ checkout solution too. Whether you want to build your own completely bespoke checkout or utilise a well known third-party offering, such as OneStepCheckout, which works without modification thanks to the same fallback module provided by Hyvä Themes that allows the standard Luma checkout to work.

Finally, Hyvä are also working on a further checkout option, which is an integration with Bolt.com, a ‘one click’* external checkout solution that focuses on UX (user experience), with quick checkout being their main goal, along with supporting all major payment gateways.

*’One click’ refers to being able to initiate checkout with a single button press from all key parts of the site (e.g. on product page, the mini cart and main cart page), not that the entire checkout process can be completed in one action!

In summary, there is no ‘silver bullet’ for checkout at present when working with Hyvä Themes, but the options on offer are just as good as those available to you when using a Luma based theme.

Commerce / B2B

We haven’t talked about feature coverage to this point, so first, it’s worth noting that Hyvä Themes has recreated almost every piece of storefront functionality in Magento’s Open Source (free) version. Magento Commerce, the paid version of Magento that offers additional functionality, along with their B2B (Business To Business) Suite, have yet to receive much coverage. However, Page Builder (Magento’s Commerce’s advanced CMS offering) and few other items are the only areas to have been recreated.

A list of completed and upcoming features across Open Source and Commerce is visible within the Hyvä Themes feature matrix.

Therefore if you’re building out on Commerce, with or without B2B, you’ll need to outline the areas you want to utilise (again, only on the storefront, backend/admin panel functionality is not affected) to ensure they are recreated as part of your project. Also, whilst Commerce contains a vast number of features, it’s not often a merchant realistically utilises more than a quarter or a third of what’s available.

It is worth noting that some key areas that indirectly impact the storefront are not affected (i.e. work ‘out of the box’), such as content staging & preview and customer segmentation/dynamic blocks.

In addition, many areas with significant presence at the checkout work when using the Luma fallback checkout, such as gift cards, reward points, store credit, custom customer attributes and B2B payment methods (payment on account/credit limits)*.

*These sections only partially work, i.e. at the checkout (for example, you can redeem gift cards at checkout, but the gift card PDP and customer account area section do not yet have support).

So, whilst it is fair to say there is a fair way to go to achieve a decent level of Commerce & B2B support, it is on Hyvä Themes roadmap (again see the feature matrix) and is an important part of the overall offering. At Fisheye, we’re invested in this and are actively working on supporting Commerce functionality, having already built the Page Builder compatibility module (which has been shared with the Hyvä Themes community for use by all).

Licence

Not many good things in life are free, and that applies to Hyvä Themes as well. Whilst there is a growing community sharing and collaborating code, it is not entirely open-source (i.e. free to all). There is a per installation licence for using Hyvä Themes, which will generally fall on the merchant to pay. Agency/development partners and suppliers also need a licence to access the codebase to evaluate the solution, and this can later be assigned to a project (i.e. a merchants site).

The licence cost is a one-off payment of €1000, which includes all future updates, i.e. there are no yearly or additional payments to get updates in future. The licence also includes:

  • Support (via the community Slack channel mentioned)
  • Access to all the code (including compatibility modules)
  • Access to the online documentation

In our opinion, €1000 is an incredibly low barrier to entry. Realistically, any merchant that isn’t able to meet that one-off cost is unlikely to be able to afford to utilise Magento as a platform for their eCommerce site in the first place (even on the Open Source edition).

PWA

In all honesty, this section probably warrants an article in itself (and I’ll likely write a follow-up article). Still, I’ll do my best to summarise it as succinctly as possible.

PWAs (short for Progressive Web Apps), or headless sites*, are another relatively new approach to building websites. They also offer fast/performant sites but equally aim to make websites feel more like the apps you use on your phone/tablet, adding features such as push notifications and offline support, amongst many others.

*The terms PWA and headless tend to be used interchangeably, which is not strictly correct, but we’re going to ignore it for the purpose of this article!

PWAs, particularly the offerings in the Magento space (such as Magento’s own PWA Studio and Vue Storefront), are essentially the alternative to Hyvä in a landscape where Luma is no longer good enough.

I can’t answer whether you should opt for a PWA over Hyvä or vice versa in such few words, but where Hyvä’s primary focus is speed and minimal code (incredibly lean sites), PWAs are more focused on providing an app-like experience (one of which is speed) and are often not particularly lean applications. Both can deliver fast sites* and great user experiences, but they require different skillsets and often different budgets and times to market, but this also depends on your requirements.

*At the time of writing, PWA Studio is not matching the speed of Hyvä, with a PDP scoring inline with a Luma on mobile (desktop is much better). Try out this product from the Venia demo (the PWA Studio demo store) on Google Page Speed Insights if you want to see it for yourself.

If you want a fair, unbiased comparison, your best bet as a merchant is to put out an RFI (Request For Information) for both options and see which best meet your needs/budget.

Summary

It’s now commonly accepted that Magento 2’s standard frontend (Luma) is too bloated and slow. Worse still, effecting change or simply maintaining storefronts is taking too much effort. This is at the expense of merchants in terms of lost revenue and cost development time (both of which slow your growth).

Hyvä Themes promises blazing fast performance, quicker development output, and a decrease in maintenance overhead. From what we’ve seen delivered/launched across the community so far and our own initial work, it doesn’t look like it’s going to disappoint. That’s why we’ve signed up as a partner already and are actively working with the platform both in terms of contributing code (such as the Page Builder compatibility module) as well as starting projects on the platform (including merchants on Magento Commerce)

As with any software, there will always be downsides to consider, but these are likely minor hindrances, with the benefits far outweighing any negatives in most cases. Of course, there are always alternatives, such as PWAs/headless, and we’ll follow up with a more in-depth article in the same vein as this one to compare the two approaches, whilst trying to be as impartial/subjective as possible!

Finally, to wrap up, if you want to see any of the sites that have launched, then head on over to the Hyvä Themes showcase page, or check out the demo.