Website Performance: The Load Speed Secret

Website load times are coming under increased scrutiny, as users become less patient. Faster sites promote better brand experiences, ultimately leading to more customers with higher conversions. We are here to address the question: 'How can you have all your bells and whistles, whilst also delivering a site in lightning speed?'
Published on Mar 30 2015 by Marco Rosano

Minimise 'Perceived' Loading Time

Latency, not bandwidth, is the main constraining factor today in web performance. The more external files you have, the more latency you add for each file to be requested and downloaded from the server. Maximising access to a website is our job, not just a matter of empathy. A big part of this is delivering sites that load fast.

What does my site cost? Is a great tool to show you how much it costs (in dollars) for users around the world to view your website on a mobile network.

Focus on perceived performance of pages - load the bare minimum to have the page render on screen, with minimal CSS to get something to appear, then load all the JS and site CSS after the page has loaded on screen.

Great tools to test page load times and look at load timelines (aside from Chrome Web Inspector's 'Network' tab):
* WebPageTest
* Google Page Speed Insights

All the files in the head of your HTML document are loaded before your web page is rendered (and the user actually sees some content) in the browser. 'Render-blocking' is preventing the page from appearing for the user until those assets (usually CSS and JS files) are requested and downloaded. If the page displays before any non-vital stuff is loaded, the user perceives the site as being much faster - even though it takes just as long to deliver the complete page in the end.

How do we do this?

In theory (and according to Google), the best method is to inline CSS code from the ‘top’ of the page (i.e. ‘above the fold’). By 'inline' this means inserting a <style> tag in the head of your document with only the styles responsible for content above the fold of common screen resolutions. The page loads with that, then the rest of the CSS and JS is loaded after that's done.

Adding these styles into the head can become a bit cumbersome when we're using a CMS and we require an easy solution.

Instead: a hybrid.

Instead we can use a hybrid of both the old school 'load all styles in one stylesheet via a link in the head' and this 'inline' method.

Rather than inlining some CSS (the drawbacks being: not being cache-able, and requiring the CMS to generate these automatically or on every page, meaning some of your styles are maintained in markup), try just loading your header styles in via a critical.scss file (with minimal imports to keep it's file size really small) in the document head. This is the only CSS file you link to in the head.

In the bottom of that critical.scss file, make a catch-all selector - something like:

.maincontent,
footer { 
    display: none; /* or */
    opacity: 0;
}

This applies to the rest of the page content. This will load the site header on-screen with the rest of the content (which is currently unstyled) deliberately hidden.

Loading the CSS & JS asynchronously.

Once the page has rendered, the user will see the progress because something is appearing on the screen. To the user, the page has pretty close to loaded. They're happy because that happened super fast, you legend! The CSS for the rest of the site can then be loaded and the page content will appear, all styled and beautiful. This means it's loaded asynchronously, which increases the perceived loading time. All the server has to deliver is the header and the markup before the user sees something happening in their browser; the rest loads afterwards.

A great tool for this is Head.JS. It lets you load JS & CSS asynchronously and in parallel, but execute them in order (important for dependencies). It can also load an asset only if a condition is met, else fallback and load a different one.

Wherever possible, don't load any JS or CSS in the head of your document, except for your critical.css file and the head.js file.

You can then use head.js to load in your additional CSS stylesheet(s), JS files, and call any functions you need.

If you want to be really fancy, use opacity: 0 as your style to hide everything on the page except the header, then at the very bottom of the last spreadsheet you load using head.js, set it to opacity: 1; with a transition effect - something like: transition: all 2s ease-out;.

The Result

You will need to add your head.js script near the bottom of your page and voila!

Bare is mind you will need your document head to fairly lean to begin with. This will then ensure that everything else loads as soon as the page has been rendered by adding more external document links to the head once the page has finished loading your critical stuff.

Note: If you're not showing a JS-heavy element on mobiles to say, increase page performance - you can also not load the associated JS library or styling to further improve load times.

But remember: 'actual' load time is not affected.

It's important to note that using this technique doesn't improve the actual loading time of the page. This only improves the perceived loading time of the page by changing the way in which we get the browser to load necessary dependencies.

The user can see content sooner so we're improving the perceived loading time of the site.

The goal is to keep the user happy and have them feeling that your site is great in both its looks, content and performance. This is just the performance part.