“Tell me why” – the reasons why we were looking for an alternative
Is the Magento 2 frontend really that bad? We spotted some problems while approaching Magento 2 for the first time – both from user’s, client’s and developer’s perspective.
Seemingly a fully loaded page did not look complete, because of shifting elements while loading other components in the background. The checkout itself, which is one of the most important parts of e-commerce as far as UX is concerned, appeared to users with a long delay (especially with less efficient hardware).
Clients who received the finished project weren’t satisfied with shop performance and SEO results. Google claims the page is too slow and the user has to wait too long to get into the first interaction (8.4s). The cost of default Magento 2 frontend optimization regarding Core Web Vitals turned out to be too high and performance was still unsatisfactory.
Magento tech stack is not attractive. Learning less popular or outdated solutions demotivates developers to work efficiently. It is enough to have a look at current tech stack:
▱ RequireJS - last version released at the end of 2018;
▱ Knockout - last version released at the end of 2019;
▱ jQuery - mentioned with love and respect, but we feel that every frontend developer would prefer to end this relation.
All that looked like a challenge to us – there must be some possibilities to optimize and improve. However, we did not expect it would be such a long way.
Fun fact: Backstreet Boys actually sang about Magento frontend
Our optimization
The first step was to remove unnecessary JavaScript files and turn off modules that we were not using. It turned out to be problematic, because different plugins added scripts in different ways. The modules, although seemingly not used, turned out to be a dependency of another module which we use, and eventually they could not be turned off. We could overwrite a lot of files, which is not the best practice. At the end we managed to remove a few unnecessary files however the effects were still unsatisfactory.
Solving Magento default theme performance issues one by one was taking more and more time and increased the cost of the project. We decided to look for a better approach.
We worked with other solutions like MageSuite which was a good alternative for Magento PageBuilder available only for Magento Commerce. Together with MageSuite we decided to use the MagePack to build JS files. We were hoping to resolve all Magento gripes related to the default frontend, but also here we have found some difficulties we haven’t faced before, despite a huge amount of work by the MageSuite Team (We appreciate your work, guys!). There were issues with building JS files and still poor results.
Looking for a better way
We are not the only ones who are faced with frontend performance issues. That’s why you can find a lot of alternative frontend solutions in the Magento ecosystem. Some of them are headless solutions, but is this the only reasonable direction? We don’t want to tell anybody which solution is the best because we avoid hyping and we are aware that there are many factors to consider while choosing the right technology. We want to describe our history with the Magento 2 frontend and the choices we made.
We had an opportunity to participate in a heated debate at Magento MeetUp in Poznań, where we discussed solutions such as Vue Storefront 1, ScandiPWA, Falcon or PWA Studio. As a matter of fact, every team took their own way, but we all agreed that none of the current solutions (in 2019) was satisfying our expectations.
What about PWA Studio?
For the project where a headless solution was required we were looking for the best PWA approach. At that moment we picked the safest way which was an official Magento product. So we started the Magento PWA Studio project in version 4 (the current version is 12). The technology itself, React, wasn’t problematic for us. However, at that time PWA Studio development was hot and we had to upgrade the product version every few months, which was quite a difficult process when it came to following breaking changes. Working with PWA Studio was often related to debugging and monitoring changes to know what will be delivered by PWA Studio and what we should cover ourselves.
PWA Studio and Server-Side Rendering issues
As far as technologically all that was not a big problem for us, there is one thing that PWA Studio is not able to deal with till now – complex Server-Side Rendering (SSR). For Single Page Application, Server-Side Rendering is a must to have a good SEO. Otherwise search engines will not see content as a user sees it. In the initial phase of the project, we also participated in the PWA Studio meetup conducted by Adobe, where the Magento development team presented possible solutions to the SSR problem. We knew that it was a potential challenge which we needed to respond to in order to move on. Their idea for Server-Side Rendering was to use a separate service (SeoSnap) for rendering full page source to which GoogleBot will be redirected. This service uses Rendertron, a Google Tool. In our opinion this is a half-baked solution because the page rendered by SeoSnap is different in comparison to what users see on their phones.
PWA Studio and Core Web Vitals issues
Apart from the lack of SSR there is also an issue with Core Web Vitals (CWV) changes. It is difficult to get good results in Google audits when the entire page is rendered on the browser side. It is the way of SPA implementation (Single Page Application) that has a huge impact on CWV metrics, for example LCP (Largest Contentful Paint), because the browser needs to get required content from API to render a page. In order to ensure good performance of page rendering API should respond as fast as possible. It is worth mentioning that the default Magento GraphQL API is not the efficient one and it is necessary to develop a cache layer. Additionally, PWA Studio calls API 25 times to render the category page which takes ~ 2315ms. Each request of a different page type needs a minimum 2 calls – one about the type of the page that we want to get (e.g. category) and after that we can request API for the content of this category page. It all takes time which we don't have when it comes to Google PageSpeed Insight audit (for example 2.5 seconds, for our website to meet LCP metric requirement).
PWA Studio lessons learned
We have chosen PWA Studio for better frontend performance. Thanks to additional optimization and caching API calls, frontend is very fast for end users, but we fall into the same trap when it comes to audits like Core Web Vitals – very expensive frontend optimization for CWV.
Unfortunately there are a lot of factors which have an impact on general PWA Studio performance. We should keep in mind that the frontend layer is only a part of it and it won’t solve backend issues like bad API times.
For the next project where headless frontend wasn’t a requirement we tried to use Hyvä.
What is Hyvä?
The conscious part of the community knows this term very well. Hyvä is the paid theme for Magento and it drops the default way of building frontend – literally, there is nothing of Magento frontend left. Instead, Hyvä focuses on modern solutions in a simple form. JavaScript files are loaded only if required and CSS includes only directives which are used on the page.
With Hyvä Themes we get very good frontend performance from the very beginning, which is a welcome change for the default Magento frontend. It only depends on us how fast our e-commerce will be loaded and which Core Web Vitals results we will gain.
Magento Luma and Hyvä – performance comparison
In the table below we present Google PageSpeed Insights results for Magento Catalog Page. It is worth saying that two, three years ago the results for the default Magento theme were worse by almost half.
We are full of admiration for the huge work the Hyvä founders have done. We don’t think that creating a new solution (eg. headless) means less effort, but making a current product great again does not mean feat. The constantly growing Hyvä community ensures us that the decision was right. Most popular Magento extensions already have Hyvä compatible templates developed by the community.
Why are Hyvä Themes faster?
Kicking off a project with Hyvä, we get a very good starting point when it comes to the number of blocking requests (CSS/JS code, required to render a website).
For Magento Luma the norm is ~200 files and Hyvä needs only 2 files. One request for the CSS library which is Tailwind CSS and the second one for the JavaScript library which is Alpine.js. So to render a website the user browser needs to download just 27.7kB additional code. This is a great result which is difficult to achieve with headless solutions.
Using Tailwind CSS and Alpine.js in Hyvä Themes
It needs to be mentioned that the more sophisticated the design of our e-commerce is, the bigger the size of code will be. However it won’t grow up so fast like in the default Magento approach, because Hyvä uses Tailwind CSS and the purging process which is responsible for optimizing the output file. The technology raises a lot of emotions and extreme opinions, but we will tell more about it in the next article which will focus on technical aspects.
Alpine.js is responsible for the interaction with users and the size of this library is 8.9kB (gzip). We won’t get more JavaScript code in the preferable Hyvä approach, because JavaScript code is included in the templates (yes, this is inline code) which may seem controversial when it comes to best frontend practices.
Tailwind CSS and Alpine.js are simple and lightweight, which makes developer experience much better and it reflects in easier developer onboarding into Magento stack based on Hyvä. We all know how hard it is to find the Magento frontend developer.
Beside these two technologies we won’t find in Hyvä any sad and outdated solutions like RequireJS, Knockout or jQuery UI.
What Magento features does Hyvä support?
In order to support default Magento functionalities, Hyvä developers had to rewrite them from old technologies to the new ones and that takes a long time. As a result, more advanced functionalities, e.g. available only for Magento Commerce might be not supported. During our first implementation of the Hyvä Themes we were working with Magento B2B based on Magento Commerce and we had to take care of a part of these functionalities ourselves. The same process applies to paid extensions which deliver new functionalities based on the default Magento frontend. Fortunately for the Magento community, Hyvä supports most of the default Magento functionalities and a large number of extensions. Not many custom solutions for the Magento frontend can boast about functionality support like this.
An important point to be made is that the Hyvä Themes do not support Magento checkout. In this case, we can settle for the default Magento Checkout (yes, we know…) or use Hyvä Checkout which is a free extension based on React.
If you are interested in what default Magento functionalities Hyvä covers, you can check feature matrix ⇨ https://Hyvä.io/Hyvä-themes-feature-matrix
If you want to learn more about what Magento extensions Hyvä covers, you can check module tracker ⇨ https://gitlab.Hyvä.io/Hyvä-public/module-tracker/
Summary
We think the Hyvä Themes are a good and cheaper alternative to modern headless solutions. In this way, we have a very good performance, and easier frontend stack, which is reflected in faster developer onboarding. We haven’t mentioned the costs. From the perspective of conscious Magento developers who know how much time it takes to optimize or rewrite Magento frontend – the cost for the theme is a nominal fee (1000 €). That is why we introduce projects based on Hyvä into our portfolio. We encourage you to check the Hyvä Themes live and the official documentation.
As Macopedia, we do not limit ourselves to just implementing Hyvä Themes, but we also support and contribute to the project. In the new version you can find advanced form validations developed by our team.
If you’re looking for more insights into Hyvä, discover our case study of a successful Mangento 2 implementation or wait for our next blog post. It’s definitely something that you shouldn’t miss.