Everything is about speed these days, and user expectations are higher than ever. We no longer wait for information, we want it instantly, we want to consume it as quickly as possible it and move on to the next thing.

Having a slow loading site is a surefire way to hack your users off to the point they don’t return – and what’s the point of putting all of the blood, sweat and tears into a beautifully crafted website if it’s slower than a herd of turtles stampeding through peanut butter. And the consequences are even more severe if your site sells a product, as we all know conversions are king, and slow page loads more often than not lead to slow conversions.

If that wasn’t reason enough, Google have made no secret about the SEO implications of a slow page load, they even provide a handy tool for testing your page speed, it also provides a rather fine set of suggestions on how to speed it up. So if you value your rankings, and you value your users, read on!

So what is a good page load speed? I personally like to see 150ms or less for the main request to the browser. This gives the user that ‘instant’ feeling. The main request being the actual generation and output of the page on the browser, not including page resources such as images, CSS and Javascript.

Optimising a simple website for page load speed is easy, optimising large or complicated website… is not. There are two main areas you need to look at to increase the page load speed, and that’s the backend and the frontend.

The backend refers to the server processing time to generate and output the page, which is affected by things such as the server specification and the quality of the code running the site. For example, a slow server, poorly written PHP code, or slow MySQL queries can all cause the page generation time to increase. If you’re aiming for 150ms, then you’ve only got about 100ms for the server to generate the page, leaving 50ms for it to be sent and rendered in the browser. We’ll look at optimising the backend another time, for now lets stick to the frontend.

When we say ‘frontend optimisation’ in this case, we’re referring to how quickly we can fully render the page, including static resources (images / CSS /Javascript / Fonts et al). So by the time the main page has loaded in the browser (ideally 150ms) your external resources should be on the way down to the browser and starting to render – in the blink of an eye your page should be in front of the user in all it’s glory. So, how do you achieve this if you have a site with a ton of CSS and Javascript, a few external fonts, and a bunch of images? In this post we’ll look at a high level overview of the techniques involved, and in later posts I’ll detail each one with practical examples.

Combination, Minification and Compression

Lets say, for example, your site currently has 5 CSS scripts and 3 Javascripts loaded in yourtag. They may only be 10Kb each but the size is not the problem, the problem is that each file (8 in this case) has to be downloaded individually and sequentially. Meaning your users browser has to create a network connection, request the file, download the file and then close the connection… 8 times. Modern browsers can manage several requests at once (up to 6), however by the time you factor in all of the assets on your page, this can still end up rather slow.

So although your user maybe on the super duper fast as can be BT Infinity (other fibre optic based broadband products available) they may as well be on their Nan’s dialup, because the fastest connection in the world won’t help here. Why? Because it’s not about bandwidth, it’s about latency. A realistic example is that takes 20ms for your user to send data to your site’s server, and your server takes 20ms to send it back. So for each file, it will take 40ms to request the file, and another 20ms to receive the file, and another 20ms to close the connection. And because each request is done sequentially, and you’ve got rather a long, and rather noticeable wait to get all of that CSS and Javacsript.

So the solution; Combine your CSS into one file, and you combine your Javascript into another file, meaning your user’s browser only has to make 2 requests as opposed to 8. It’s not rocket science, and it’s not that hard – it can be as simple as copying and pasting the contents of each file one after another to create one file. Although in reality there are tools which can do this for you automatically, meaning you can continue to develop on individual files rather than getting into a bit of a mess.

Doing the above will generate one single file, however, in most cases this will have become quite a large file size due to the amount of code in it, so this is where minifying and compression comes in.

Minifying is done via a ‘minifier’ – a small script or program which will read your CSS or Javascript file, and remove all of the white space, line breaks and code comments. Although the output isn’t very readable, and you certainly don’t want to be developing on a minified file, it will shave a few more all important Kbs’ off of your filesize.

Lastly is compression. This is a server side setting which will service your CSS and Javascript files zipped to the browser, this can cut huge amounts of filesize from your file, as much as 80%.

Content Delivery and CDN

Browsers can only download files from a single domain sequentially, that is, one after another. So when your user loads the page, they request the main page, e.g. index.php, the browser then gets the javascript files, the css files, and the image files (depending on the order they are in your page). If you’ve got 20 or so images on a page, they will need to come down one after another – so again, although your user has super fast internet, your site isn’t allowing them to utilise their full bandwidth, because it’s being limited by the network latency of creating those 20 connections to pull down images, one at a time.

So to solve this, use subdomains for your content delivery, and/or a CDN. If you put your images on images.your-site.com and your CSS files on css.your-site.com, and your javascript on… (you get the idea), then the browser can download all 3 items at the same time, greatly improving your page speed. If you want to go one further, use multiple image subdomains such as image1 and image2.your-site.com. However, don’t go too far, 5 will do, otherwise the DNS lookup time for all of those subdomains will start to outweigh the speed advantages.

A global CDN (Content Delivery Network) can do the above for you, and with the added advantage of being global, it will cache and serve the files from POPs (Points of Presence) geographically closest to your user.

Expires Headers

Setting far future expire headers on your static content will tell the browser to store a copy of your static files locally, meaning they don’t need to re-request them from the server on each page load, or if your user comes back in a weeks time. The downside to setting far future expire headers is that every time you change your CSS/Images/Javascript, you’ll need to modify the filename, so your users browser looks for the new version.

Request Timing

Traditionally, due to the HTML specification, developers would place the links to their Javascript files in the section of the site. Now it is much preferred to place the links as close to the closing tag as possible. This means that the browser will render the page first so your user has something to see, before downloading Javascript as in the vast majority of cases, the Javascript can be loaded later on as it’s not so time sensitive.

And that’s Part 1 of our Frontend optimisation guide. In Part 2 we’ll look closer at each item and explore the technical side in detail.