Speed Is Key! Increasing Your Website‘s Performance

Knut Gollert
make better games
Published in
5 min readMar 24, 2017

Building a performant website means first and foremost building a fast loading page. Not so much for SEO reasons, but for a neat user experience. It’s quite simple: Visitors won’t churn as much if they see things right away. I will shed some light on my approach on how to get all the browsers out there to load pages faster.

It’s a well-known fact: Making your website faster will increase your clients’ conversion. The ranking will go up, the page views might explode. The bounce rate will go down. All major outlets like Google, Yahoo, Netflix spend weeks testing these results. It’s true.

People are considering anything under 0.1secs/100ms as instantaneous. Your website‘s loading time won’t be that fast due to our dated DNS Lookup system and TCP protocol. But 1 second — considered as “in flow” by most people — is definitely possible in the future. Today a good and fast website needs to be visually complete above the fold in about 3 seconds. And this is completely independent of the total size of your page!

CTRL+SHIFT+I — The magic is already built in your browser (this is Chrome’s dev console)

But how?

First of all, one should minimize the size of all assets queued to load. Images should be jpgs, I recommend using a tool like RIOT to minimize their size. PNGs or better SVGs are great for Icons or any vector elements. Other sources (html, css, scripts) should always be minimized and if possible put in one file (for css and scripts). Staying with your server for all scripts instead of using CDN-hosted files might also be a good idea (if you’re not expecting huge traffic). This will generally decrease download time.

But that’s still not the real deal. To understand the following steps, we have to look at the browser and how it starts to show these funky pieces of content you desperately wish to be viewed in time.

Browsers are downloading the html file first and are starting to work through it from top to bottom. Normally all the important css- and script-links are located in the head section. As soon as the browser stumbles upon them, it starts to download them. And it waits for them like “Yeah, I need those to know what to do. So let’s first see what they’ve got before showing off anything.” Which means css and javascripts are render-blocking. The browser does not paint anything before it caches them. This is the biggest hurdle. We need the browser to show things right away!

Javascript last, please

As javascripts are not blocking the rendering per se, but only the DOM (Whats the DOM?), we conveniently move them to the end of our html file right before the closing </body> tag. The browser will get to them eventually and they will not block anything.

Another way of loading them is adding the async attribute like this:

<script async src=”/js/script.js”></script>

Unfortunately, if your scripts are on the bottom of the page this won’t help you much. It might even be a bit dangerous, because your scripts might depend on each other. An async-loaded jquery.js might not be ready when your own small script.js is, which is using jquery functions and therefore stalls.

Minimized inline CSS in the head makes your page ready to render really fast.

CSS is critical

Your style sheet on the other hand is really important for the browser. It needs to stay in the head because it needs to be downloaded early on, but it prevents the rendering of your page, even if the style sheets are not critical to the initial rendering.

A good way to handle this problem is to put all the css the browser needs for the initial, above the fold, content rendering in line to the head (<style>…your styles…</style>). The rest of the style sheet will then be loaded by a script like loadCSS and therefore will not be treated as a render blocking resource by the browser.

@font-face-palm

But the most underestimated performance suckers are custom fonts. It’s not like they block rendering per se, but if you load some of the bigger web fonts with 100kb to 200kb and you’re using the above mentioned CSS loading method you will get confronted with the unwanted FOUT, or even with the most undesired FOIT. FOUT stands for “Flash Of Unstyled Text” and means that the browser shows all text in a fallback system font as long as the custom font is not loaded. This results in a short, uncomely FOUT. FOIT is the “Flash Of Invisible Text” — sometimes shown by browsers during downloading the web font.

You can counter these effects in a couple of ways. From using less web fonts to loading them via a font loading API, using the smaller woff2-fonts or even editing them for your own purpose by deleting unneeded characters (viable for these huge icon-fonts for instance). The good news: there are lots of ways to optimize font usage on webpages. The bad news: There is no perfect solution! Good articles to find your very own method to get rid of slow-loading fonts, FOUT or FOIT are these: https://www.viget.com/articles/the-font-face-dilemma or https://www.zachleat.com/web/comprehensive-webfonts/.

The same website with different CSS and JS loading approaches.

Test it

So, how can one be sure our page loads fast? How can we identify any problems and show stoppers? First thing to look at is the waterfall tab in the developer tools in your browser (for instance CTRL+SHIFT+I in Chrome, Tab NETWORK or TIMELINE). A really cool external web source is webpagetest.org where you can even get a video of the loading sequence of your site or a visual comparison of as many sites as you want.

And what about mobile?

Mobile web users are in desperate need of information. They are not just browsing the web for fun. They are on the move and look for stuff they need right now.

In designing websites, I aim to give them these infos as fast and as clear as possible. They don’t need fancy sites with gaudy css animations. That’s why I tend to design dedicated mobile pages which are basically stripped down versions of desktop originals. And I like Googles AMP a lot. It’s basically a set of rules you use to make your mobile page load really fast. It gets rid of external style sheets and scripts, which is harsh, but eliminates the main load-time-suckers.

Coding AMP Pages is pretty fun. Although you will miss all the page speed optimizing fun while building these. Fiddling around to save some milliseconds here and some others over there is finally pretty rewarding.

--

--

Knut Gollert
make better games

Art Director, Graphic Designer, Web Designer, Video Producer, Coder — pick one.