A guide to page speed insights and optimising page load

We have recently updated our own website and as part of the process of the rebuild, we run the new site through Google's PageSpeed Insights in order to get the site running as efficiently as possible, and in order to get the highest number we can. We continue to learn a few things on the way, and this guide will outline some of the steps we took to ensure our load speed was as quick as possible.

 
A guide to page speed insights and optimising page load
 

We have recently updated our own website and as part of the rebuild process, we ran the new site through Google's PageSpeed Insights in order to get the site running as efficiently as possible, and in order to get the highest number we can (we can be a little competitive like that!). We continue to learn a few things on the way, and this guide will outline some of the steps we took to ensure our load speed was as quick as possible.

PageSpeed Insights is of course very good at telling you what is slowing your website down, and gives good examples of how to approach different scenarios, but outside the bounds of that, there are a lot of things that it doesn't suggest. I'll run through some of the things that we integrated into our setup, and why we made some of the decisions we did.

Mobile User Experience

We got 100/100 on this one first time round, but it's not really our backs we should be patting. We have been incorporating Zurb Foundation (http://foundation.zurb.com) into our sites for a while now because it provides a simple and efficient way of building sites responsively, as well as efficiently. We have stripped a substantial amount of time from our builds because we no longer re-write a lot of code and get everything set up by ourselves. We like Foundation.

Running through the list of mobile user experience pressure points, Foundation covers all of these off, and ensures a great experience for mobile users. Be sure to include the viewport meta tag too and you should be all set:

<meta name='viewport' content='width=device-width, user-scalable=no, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0'>
Speed

We also passed most of these. It's worth noting that you are always going to have to make decisions and sacrifices somewhere along the way, but if you have a clear understanding of what you want to achieve, these decisions become a lot easier. For example, because we use Foundation, all of the CSS is held in one file, which we are happy to remain render blocking because the saving in loading it after the page has loaded is minimal, and you get the Flash Of Un-styled Content, which we really didn't want.

The other really important aspects here, are getting your server and content set up correctly. Serving images that are 3000px wide and several megabytes in size should be avoided - resize them to the size they are likely to be on your site and then save as an 80% jpeg. This is fine for background images that are in place to support text, where the quality of the image is less likely to get noticed. Further to that, we use a great little tool called ImageOptim (https://imageoptim.com) that losslessly compresses the images and gives some huge savings in terms of file size.

Setting up gzip on your server, as well as expiration dates on cacheable content will save further time, but focusing on your server response time will help all of these in turn. This is the area that we analysed the most and worked hardest to get the most improvement on.

Server Optimisation

There are a few key areas that we approached in order to improve the response time of the server. Firstly, we wanted to further optimise the efficiency of the application itself by stripping out anything unnecessary and re-writing sections that might use greater resources than required. We use Symfony (http://symfony.com) for our application builds, and there is some overhead on this but the pros in every other area far outweigh the minimal hit you take in terms of speed.

So, with the application sorted, we explored how we could increase the server time. As I mentioned, we have already set up browser cacheing and gzip on the site, optimised images and minified scripts and css, so the site itself is working at maximum, so how best to get this information over to the user? We found two answers to this: set up a reverse proxy, and set up a content delivery network (CDN). These two changes really took the site to the next level.

It is worth understanding though, that when I say that the site went to the next level, we cut our page load times down from an almost imperceptible level to a slightly more imperceptible level - the site runs now at around 600ms for a full page load, but again, this will differ depending on where in the world you are and the load at any given time on the server. We are trying to achieve the maximum efficiency we canwith the page loads and to ensure, even though there will always be variation, that we can keep it to a minimum.

So, what did we do? Well, we set up Varnish cache on the server (https://www.varnish-cache.org), which catches incoming requests to the server and returns the requested information immediately, without having to ask the application for it. Depending on your architecture, Varnish can give you increases of up to 1000x. We're very impressed with Varnish.

Further to that, and in order to decrease the number of calls to our server, we set up a content delivery network. The essence of these is to distribute the load that requesting assets (images, css & javascript files etc.) places on the server, across multiple servers in locations that are close to the requester. This helps avoid latency issues, and means that your server doesn't have to deal with a high load of requests.

We decided to use CDN.net (http://www.cdn.net). We chose these guys based on price, and flexibility on where you want to serve the content from (which can be truly worldwide if required).

We've covered the challenges (albeit small) we face in incorporating the CDN into our application here, and once it was set up, it again provided a big boost to the delivery of the website.

January
January