How to increase page speed score with Storyblok

In our previous article we established the importance of page speed and now it’s time to see how it can be achieved or improved using Storyblok. In other words, we will take a look at reducing page loading time.

Below are a few best practices from one of our Storyblok ambassadors and a case study.

How assets treatment can impact page loading time

Assets have a great impact on the loading speed and, subsequently, on its page speed score. One way of improving the loading speed of a page is to preload key requests, to prioritize the preloading of critical assets. Another way is to preconnect for connection to third-party origins.

Yet another solution for third-party embedding is to use lazy-loading by loading a static element until the user interacts with the element (ex. on click).

Of course, the best option is to limit third-party usage as much as possible and to load it after the page has finished loading.

You should also consider eliminating render-blocking resources by delivering critical CSS/JS inline and deferring all non-critical JS/CSS.

It should go without saying that all JS and CSS files should be minified and all such unused files should be removed. More than that, you can remove large duplicate JS modules from bundles.
In fact, when working with CSS frameworks choose only that is modular or employs CSS-in JS, enabling you to load only what you need.

When it comes to images developers should serve responsive images and to consider lazy-loading hidden images, after the critical resources have been loaded. The CDN service provided by Storyblok can help with the compression and optimization of images.
Also, consider using explicit dimensions for the image elements to improve the cumulative layout shift, which is part of the user experience ranking signal.
Whenever possible avoid delivering animated content via GIFs and use MPEG4/WebM videos instead. The CDN service, once again, can help with the conversion to HTML5 video from GIF.

Last but not least, use system fonts, while loading the custom fonts.

Case Study on page speed improvement: UPC Business Switzerland Website

With UPC Switzerland we see the power and magic of three come to life. A team of 3 developers from twim, built the new fast, agile and responsive website in 3 months. The new page is now almost 7 times faster than the old one, a clear increase in website loading speed.

The team at twim opted for the following technical stack: Storyblok (headless CMS), Netlify (hosting), Nuxt.js (Framework) and Github.

Using a JAMstack architecture with Storyblok, the new website has 500+ pages in four languages and it went from loading time of 20.6 seconds to 3 seconds.

Here is a full picture of the reduced page loading time with JAMstack - javascript, API, and markup (html):

The main objectives of migrating to Storyblok where to improve the editorial workflow, to reduce time-to-market and to improve the performance of the page. Due to the outdated website architecture of their old legacy website, the site was heavy and slow.

While all three objectives are important and Storyblok plays an important role in achieving them, in this section we will focus on the improved performance of the new website. Specifically, we asked two of the developers what their solutions were and you can see their answers below.

How did you improve the page speed with resource treatment?

There were a few things. Asset optimization is one of the most important things. Specifically, using the most modern formats for images: webp. Also, lazy-loading the hidden images and using responsive images. Content editors can now choose what image resolution they want to use, depending on the device they will be displayed on.
The same goes for iFrames and videos, we used lazy-loading for them. Youtube embedded videos can take up lots of data.
Another change was using the most modern font formats, specifically woff2.
When it comes to JS/CSS files we preloaded the critical ones and, it goes without saying, we minified all of them. We minified them on a compiler level and then we compressed them using gzip or brotli. Additionally, we split the JS by routes.
Another action we took was defining assets we wanted to preload in the html head. That’s what we used for some fonts and critical CSS. For example, the hero image.

Was there a correlation between site performance, bounce rate and conversions after the migration?

We don’t have exact figures on this, but it is safe to assume that the increased performance had an effect on the bounce rate and implicitly on the conversion rate.

What did you do in terms of reducing the analytics code?

We had some recommendations but in the end we didn’t implement them because they decided to keep things as they were.

Do you have other general recommendations?

Yes! Reevaluate the analytics you need for your website. Importing different third-party applications will critically affect the speed of your website. See if you can reduce/combine some of the packages or postpone the loading of the ones that are not crucial until after the initial loading of the page. Check the performance after each analytics code you add to the page.

In our opinion, Google Tag Manager should be managed by the developers team and, of course, lazy-loaded.

How the page is built is crucial and can make a considerable difference in terms of speed. If you use, for example, React.js or Vue.js for generating the pages the main issue is with what is server side rendered and what is client side rendered, because there is the risk of loading the same data twice. Our advice is to focus on and improve the hydration process.

Another speed optimization is using HTTP/2, and gzip, deflate or brotli for compression.

In the end, if we would focus on only two main things for speed improvement, it would be the way we load and serve images, and analytics.