Landing page speed - Breaking the 1 second wall (Part 1/2)

In this third post Àlex Cabrera, lead developer, will discuss about the importance of having a clean, fast and appealing landing page on our game web site. 

Landing page speed - Breaking the 1 second wall (Part 1/2)

It’s common to see how experienced developers –I was about to say experts, but I don’t like that word- highlight the importance of having a clean, fast and appealing landing page on your web site. At U-Play Online, we knew all that stuff, but we didn’t pay the attention it deserved until we saw our own landing page loading time (Striker Manager). Between 5 and 6 seconds.

All began with Google I/O 2014, where we could test our site on the Device Lab. And thanks to +Matt Gaunt and +Pete LePage, we realized that we had a lot of work to do in order to improve our first impression.

Striker Manager 2 Live demo

This document is not about what users want neither what users need. Here you will find some of the techniques we used to reduce our loading time from 5s down to 1s. We are not going to dig deep on mobile specific optimizations as our landing page was only for desktop (a native app is being developed to fit mobile needs).

Server optimizations

Delivering a landing page should be the most straightforward work that a server can do. Ideally, an static and plain html file. However, we live in a dynamic world personalized by suggestions, so server side work is normally needed to print what we think users expect to see. Be careful. Server-side processing means extra delay, especially if complex database queries are involved.

It’s also very important to simplify the path that the request follows to your landing page. Like at previous point, the simpler the better. Locate the page on the default file (/index.html, /default.html…). The path that the request goes through will slow down the content delivery. Avoid redirections at this step of user visit. Think of a header(“Location: … “); in php, that goes back to the browser telling him to go to a new url, so the request will make 2 times the same journey to the server. This may seem ridiculous, but in mobile environments, it can make the difference.

This chapter can’t be closed without mentioning the great gzip. It’s usually missed due to it’s easy configuration. It compresses -as much as it can- the data that your server delivers. Don’t forget it. Nowadays most of the browsers accept compression. And you only need to activate a flag to enable gzip, it’s not a big deal!

JavaScript optimizations

Using JavaScript in web pages is a very powerful but tricky weapon. You can pre-load content in web-shows, handle user input to respond gracefully, avoid page reloads when error occurs, display awesome animations… but at the same time you can be omitting critical behaviours that will slow down your page load and turn into your worst bottleneck in all the process.

“Only load what you need”. That’s the key. Browsers are not humans, they don’t need comments to know what that var means. They don’t even need line breaks. So use code minimizers. Those services delete all the useless comments and line breaks all over the file. That saves space and time. There is also the possibility to change internal parameter names and private function declarations to reduce the footprint without losing coherence with the previous features. You can even join a bunch of files into a big minimized file reducing the needed requests to load all the content.

Another way to diminish file-loading time relies on highly used scripts. Nowadays, anyone visiting your site has probably visited before other sites using jQuery, Bootstrap or AngularJS, for instance. Imagine all that common resources were loaded from a single deliverer, so all sites could share those files and reduce load times on a global scale… Stop dreaming, it’s true, and it’s called CDN (Content Delivery Network). If you are using some of those freaking-common libraries, you should be using a CDN. They will definitely have better load times and uptime rates. Also, the chance to find a cached copy already on the browser is really high, what means that you won’t need to reach up your server to download the file.

Once seen the ways to reduce the page load delay, we should clarify where to locate it on the html hierarchy.

Browsers -obviously- parse the html file from the top to the bottom and they start interpreting all the data until the end. If we locate a slow blocking JavaScript code at the beginning of our beautiful landing page, the last elements won’t start rendering until the JavaScript snippet ends its work. The result: a useless and easy-to-fix waste of time. The best approach is to push all the “script” tags to the bottom of the page. Delaying script run until page load event is fired can also be useful, as we let browser finish its work before starting ours.

Optimizing CSS

CSS may seem the simpler feature to reduce size, as most of the times is composed by short and repetitive statements.

It’s true that minimizing tools do a great job, but the hardest work lies on early days organization. CSS is the responsible for telling the browser how the bunch of html elements will be displayed, a.k.a. rendered. A messy overriding CSS structure will slow down the rendering process and will result on a larger CSS than needed.

Although it’s better to join all CSS files to reduce server calls, the landing page is time critical, so it’s worth the time to arrange a specific CSS file to avoid loading useless styles.

Nowadays responsiveness keeps on growing as an awesome way to go. It’s not that cool. Media queries (the feature beyond responsive design) add a lot of CSS rules that will never be used in a specific device. A hard statistic study has to be done to see if responsiveness is a need or server choosing CSS is a better way to proceed.

HTML optimizations

Your HTML file is the basement and contains the rules that the browser must follow to build the page. It’s very important to choose wisely when everything will happen. When will scripts and styles load can handicap the rendering speed of the site.

Even simplifying the structure of the “visible screen” can help to improve the speed perception. The visible screen refers to that section of your landing page that is visible in the browser frame, the only thing that will be seen at first. It’s always useful to recheck the code and see if you are using 3 elements when you could be using just 2. Eventually, you will have a simpler structure with less rendering times.

Finally, there is an effective way to reduce server calls: embed all JavaScript code and all CSS styles directly into the HTML file. That reduces server calls, style interpretation delay, JavaScript compilation delay… But you lose cache benefits. You should better find an automatic way of doing that when deploying or you can break all contact with reality while maintaining that file.

As you can see, there is no magic in doing a faster landing page while keeping a great design and user interface. On the next article we will dig into image optimization, which deserves a full chapter for itself.

Useful links:

- Google’s library CDN

- Bootstrap CDN

- Page Speed

- Closure service

- Google Chrome Dev tools