The CRO Course: Win on Mobile

Blog post:
How the Nordic TUI engineers fixed speed

An organizational setup with agile processes and engineers being listened to by stakeholders gave the Nordic TUI team what they needed to fix speed. At Think with Google you can read the case about how to set up the organization, but here, we treat you to an in-depth description of what the engineers actually did to succeed.

When selling on digital platforms, organisations win when a dialogue is created with digital experts. This was the insight TUI in the Nordics had when their engineers started bringing up speed after a Speed Hackathon with Google. The stakeholders understood that the engineers were on to something important for business revenue, so they gave the engineers time and resources to work on speed – and trust to build their own process.

The result: 

• Load times decreased 78%
• Bounce rate decreased 31%
• Relative mobile conversion rate increased 11% 

At Think with Google you can read the case about how the organisation changed their way of working, but here you can dive into Emil Wiklund’s, Lead Frontend Developer at TUI in the Nordics, blog post about how the engineers solved speed: 

How we got the basics in place

1. First we moved from http to https.
2. Then we moved from http1.1 to http2.
   
   
3. After that, we changed from a monolithic platform into a headless CMS where data could be stored and an api could be used to generate static html files. This made it possible for the developers to make changes to the code fast.
   
   
4. The old platform was build together with an offshore organisation consisting of 14 scrum teams. When shifting the CMS to the new platform, I (Emil) had an inhouse team of six developers plus a product owner. This made the inhouse team fully in control of the code, and we started migrating page template by page template, making sure that all that was moved actually where in use.
   
   
5. The code was rewritten into plain JavaScript so it could start executing before jQuery had loaded.
   
   
6. A new cleaned out main scss file was created, only including necessary code for the components used. The rewrite of the JavaScript and the css made the pages load twice as fast with very little effort. So after we were done with this basic stuff, we started with the more advanced parts.

Images

The new cms platform came with a great image api, so our editors could upload 100% quality images in high resolution but the images became responsive with different sizes depending on the user's device width. We also started using webp image format with jpg as fallback and made sure we lazy loaded images on every place where it made sense.

One drawback with the image api was that it was served from another domain then TUI. So, the DNS lookup and SSL handshake had to take placed. We solved that by having a proxy in our varnish cache that all our html, js, css, images and other assets are cached in. Finally, the top logo was a svg file which we included via the src attribute on an image tag. But that required an extra request. So we inlined the svg instead, making it possible for the user to see the logo much faster since it was already in the html response from the server. 

CSS

The biggest improvement we have done with the css is to inline the css needed to render the above the fold content. We are using the npm module critical from the brilliant guy Addy Osmani. Then the rest of the css is loaded async with the technique from Filament group. That made a huge improvement for the first paint. We used to have a lot of css from bootstrap. We have part by part removed stuff from our bootstrap dependency and by that getting smaller file sizes. We are still not quite satisfied with the amount of css we deliver. But it’s a work in progress to reduce it even further. For the homepage we have a separate css file in order to make the page load fast. 

JavaScript

As I mentioned before, my team has removed all jQuery code. We still serve jQuery to the client though since we have some widgets and 3rd party tracking scripts that require jQuery on our pages. We are working in the direction to be jQuery free but we are not there yet. But if we take care of loading jQuery we can do it the fastest way possible. We have put the defer attribute on all script tags. Some of the script that are not required for showing content above the fold we lazy load after the onload event.

A/B Testing tool

We used to have a 3rd party A/B testing tool that sent a bit over 100 kb gziped JavaScript to the client. Which at the time was around 15% of all JavaScript on the homepage. Because of the huge payload we didn´t want the scripts to be render blocking so we loaded them after the onload event. The downside was that we often saw flickering when the original content was replaced by the variants. The way we used the A/B testing tool was basically that we wrote JavaScript and css that was injected in the DOM. So we figured that, why not do this in our CMS? So we did. We ended up with under 100 rows of JavaScript that is the core that does the manipulation of the DOM and send events to Google Analytics.

GTM and 3rd party script

We moved the execution of injecting GTM after the onload event. GTM in our case is responsible to injecting all tracking scripts and such. We have not seen any drop in tracking because of this. But this way, we don’t have to worry about poorly implemented scripts that block the rendering of the page.

Fonts

Fonts are downloaded when the browser founds html that matches a css rule, which can take some time. We got fonts to load faster by using woff2, which has the best compression, and by instructing the browser via the browser hint preload with this code:

<link rel="preload"
href="/cdn/fonts/type-1.020/tuitypelt-1.020-webfont.woff2"
as="font" type="font/woff2" crossorigin=" ">

We used to have an icon font for icons on the site. Since fonts are slow to load, we have moved over to an svg sprite with icons instead. 

Extra

We used to on every page download all files required to use our 3rd party site search app on load. But since the user doesn't need that before he or she decides to make a search, we now load the required files when they activate the search via the search icon.

Also, we have set long cache headers (about a year) on all of our assets and everything that should be gziped is gziped.

“Looking back, the key success factor for us has been that we’ve been given time and trust from the organization. We are trusted to judge for ourselves what to focus on and how to solve the problem. Second to that, it has been our ability to deploy changes as often as we need. Some days I’ve deployed tens of times to see if small tweaks made a different. With a traditional approach, with releases weekly or biweekly, you feel scared to do something that will be less good, since you have to wait weeks before you can fix it. This way, we can learn fast which is what it’s all about”, says Emil Wiklund. 

Looking back, the key success factor for us has been that we’ve been given time and trust from the organization. We are trusted to judge for ourselves what to focus on and how to solve the problem. Second to that, it has been our ability to deploy changes as often as we need. Some days I’ve deployed tens of times to see if small tweaks made a different. With a traditional approach, with releases weekly or biweekly, you feel scared to do something that will be less good, since you have to wait weeks before you can fix it. This way, we can learn fast which is what it’s all about.

Emil Wiklund,
Lead Frontend Developer at TUI in the Nordics