How to destroy your Lighthouse score with Hyvä

The default - a summary

Hyvä gives you a frontend with Tailwind CSS and Alpine JS: With both libraries added to Magento (and more importantly, all of the old fluff removed), the number of HTTP requests - besides the HTML document - drops to two: One request for the Tailwind CSS bundle. One request for the Alpine JS library - additional scripts are loaded inline. Great. But this automatically means that adding additional requests brings down the performance of your site (which is one of the points below).

Whatever you do to customize Hyvä endangers the default performance.

About Lighthouse score and this blog

Disclaimer: This blog is not meant to debate whether or not a Lighthouse score is something you want to keep an eye on. Havig a high Lighthouse score is nice. Having a very low Lighthouse score is bad. Having some score in between might still give your users a good user experience and it might not be bad for SEO either. This blog is not about how useful Lighthouse is.

Using a slow Magento backend

Hyvä its CSS and JS is fast. But if a product page its HTML is loading in 4 seconds, the overall performance will still be bad. And how to get to such a slow PDP? By adding any kind of extensions without performance testing and thorough reviewing.

The more functionality is added through third party extensions, the tougher this will be to manage. What if a single module adds in 100ms (which is not that much, you think) but you then add a dozen of these modules? In short, you still need to guarantee that the Magento backend is fast.

Caching the pages is definitely one useful approach here: Using the out-of-the-box Full Page Cache of Magento, but preferably by using a separate Varnish (that does not run via the same webserver that serves Magento). Not caching pages will cause a slow frontend, thus lower score.

Adding additional CSS & JS (without a budget)

Say you've got a clean Hyvä theme, scoring above 90 with Lighthouse. Next, add in support for Twitter, Facebook, LinkedIn, Disqus or other social media thingy and most likely the Lighthouse score goes down immediately. Often, integrating such a widget is not adding just a single CSS or single JS source, but adding a chain of requests where common standards like not setting cookies when not needed are absent.

A performance budget might help here. Say the score is 97. And before you add new features, you aim for the score to drop not below 90. Write this down on paper. Next, if the module causes a drop below 90 after all, remove the module. Perhaps pick another module. Or write your own module. Or forget about the feature. Or add the module anyway and forget about scores in the future :)

Note that performance budgetting is something that could be but must not be related to Lighthouse scores directly. There are many techniques and methods out there for maintaining a budget.

Fallback too often

The Hyvä suite includes a fallback module that allows you to fallback to a Luma-like theme. This is quite popular when it comes to the checkout. Instead of implementing a React checkout or wait quite some time (sorry, understatement) for a Magewire-driven checkout, you could just use the original Require/Knockout checkout with its full feature-set and horrible performance.

Instead of using this fallback on the checkout pages, you could also decide to use it for product pages or category pages. Once you go down this path, you might as well just drop Hyvä alltogether. But still, it needs to be mentioned here in this listing.

Theoretically, you could say the Lighthouse score is also bad when using the Hyvä Fallback for the checkout. But SEO should not matter for the checkout. Instead, user experience should matter. To my opinion, the React Checkout does add a much better experience (focusing upon the loading of resources, not focusing upon the UI) then Luma checkout. But if you can make the checkout fast again (Knockout replacements, JS bundling, etc) this can be debated.

Adding remote fonts

To make sure that we are not stuck to only using Times New Roman and Arial, adding remote fonts - like with Google Fonts - is quite common these days. But bare in mind that each font brings in its own OTF, TTF or WOFF1/2 file and thus adds weight to the page.

Even worse, if you follow the procedure described on the Google Fonts site itself, you will also be downloading the CSS definition from them, before proceeding with downloading the fonts. Copying the font files to your own site (with PostCSS thus Tailwind you can use FontMagician to this for you) and hosting them yourself gives a good performance.

Using less custom fonts gives an even better performance.

Using Magewire everywhere

Willem Poortman, who is now part of Hyvä, announced at Reacticon 4 last year that his Magewire (a port of Livewire to Magento) would result in a new Hyvä checkout that could replace the Hyvä React Checkout and Fallback checkout. This checkout is yet to come, but you could already implement Magewire yourself in various pages in your shop - mainly to ease the pain of creating AJAX calls yourself.

This is nice. However, adding Magewire in too many place could become a bottleneck too. Adding the core JS library might not be too much of a fuzz, but depending too much on AJAX in too many places might be. Use it where needed, not wherever.

Using the Tailwind CSS development build (outdated)

With Tailwind 2.0 or earlier, there was no JIT compiler and because of this, there was a huge difference between the development build (easily more than 4Mb, no typo) and the production build (so 70Kb or more). Shipping the development build to production was obviously a very very bad idea. With newer versions of Hyvä, Tailwind is added with its JIT feature, allowing for optimizing the CSS build all the time - both in development and in production.

More pains

There are many more things that you could do to destroy performance, of course. For instance, adding 4Mb images to the frontend is a nasty thing. Likewise, not optimizing images (like serving a modern-day WebP alternative using the Yireo WebP2 module) or using too many images is not going to benefit your scores. I'lll leave it up to your imagination.

What is the point here? I guess that the most important point is that Hyvä out-of-the-box gives you a great performance. But this does not mean that any Hyvä shop out there in the wild will still perform perfectly. Don't blame Hyvä.