Website Speed Tips

6 Tips to Increase Your Website Page Speed - Part 2

Looking to get a better page speed on your website? Look no further...these tips will get you moving.

This is part 2 of a two part series, read part 1 here.

Upgrade your server to HTTP/2

HTTP/2 has been a long time coming, for too long we’ve been building on top of a legacy protocol, this means a lot of our techniques have been put in place because we’re working with HTTP/1.

One of the many benefits of HTTP/2 is that we can now download assets in a much more fluid way, HTTP/1 forced us to download assets in batches, this was useful to keep connections open but meant we’d wait for the largest file to finish before we could move onto the next batch.

HTTP/2 has done away with this meaning that we can now download assets as soon as we finish any other asset currently being downloaded, this means that techniques like concatenation of files and turning images into sprites are now not best practices and should be avoided, favouring more smaller files which can be downloaded and displayed to the user as and when they get delivered.

HTTP/2 does have some requirements, one of which being browser support, the other being that it must be used in conjunction with a valid certificate. Both of which aren’t a problem to get over to help you reap the rewards of HTTP/2.

HTTP/2 has other huge benefits, Daniel Stenberg has written http2 explained if you’d like to dive in deeper.

Optimise for the critical render path

If you’ve use Google Page Speed Insights, you’ve seen this phrase. This is a much more complicated challenge than anything else we’ve discussed so far, but I’ll outline what we’re trying to achieve here.

The critical render path defines the assets required for the browser to do it’s first render, this means everything the browser first sees when scanning the initial HTML that’s delivered. The challenge of optimising the critical render path is all about prioritising your assets to get that first render as quick as possible.

This means we may want to delay our JavaScript completely, we may even want to delay a large section of our CSS and only focus on what the user can see which, if they are on mobile, could be as little as the header and some initial content. The goal here is to try and make our critical render path so small, that even on a very slow network, we could get for that ever ideal goal of our first render happening in under 1 second.

The reason this is a more complicated solution than anything we’ve discussed previously is that after we’ve delayed all those assets we then need to pull them in in a way that isn’t jarring for the user and doesn’t impact the rest of their experience. We still need all these assets delivered quickly and giving to the user without them noticing.

Ilya Igrigorik has done amazing work on the critical render path and you can see his video here.

Increase your perceived web performance

Okay, so this isn’t going to make your website faster on any metric, but it can have just as much impact on your user experience.

Perceived web performance is all about how fast your website feels as opposed to how fast it actually is.

There are a few accepted ways of increasing your perceived web performance:

Sleight of hand

I call this Sleight of hand because it works similar to how a street magician can steal your watch, we are essentially distracting the user while we load the assets to the website. The most simple way of doing this would be adding in some animation while loading in a new section of the website, if our animation takes 2 seconds and it takes us 1 second to load in the new thing, the user may not even realise it’s taken any time before they can interact with the new part of the website. If this seems pointless to you, the web already uses this a lot and you’re probably not even noticing it.

Skeletons

This is a technique that is heavily used by social media website such as Facebook, Twitter and Instagram, the technique here is basically just loading in something that looks like the asset the user is trying to get at. In the case of Facebook, who use this heavily on your timeline, it’s a dummy post, your brain is already expecting to see a post so by seeing this skeleton in place, your head is already partly accepting the fact that the page is loaded. This is really effective and although has no increase to the actual page speed, it can increase your conversion rate massively.

Keep ‘em busy

This should be saved for when we’ve got a long wait that we can’t speed up for some reason, give the user something to do. The gaming industry will often give users a mini game to play while they load the main game. This could be a simple version of what they’re going to be playing or a tutorial. We could just give the user some information, if we’re a holidays website, we could display the weather while we’re doing some heavy processes that can’t be sped up for example.

Everything I’ve said about are all web performance techniques that actually work, I’ve implemented them, I’ve seen the results and I can vouch for them.

I’d love to hear your stories implementing some of these results, equally, I’d love to hear some of your web performance techniques that do or don’t work, so please reach out in the comments.


Website Speed Tips

6 Tips to Increase Your Website Page Speed - Part 1

As anybody who knows me will tell you, I’m a huge self-confessed web performance geek, I love websites that download fast, I believe that fast internet is a basic human right and I think hotels that claim to have WiFi but instead have LiFi (WiFi that doesn’t quite seem to download anything) are criminal and should be boycotted.

This means that I’m always on the hunt for a good website performance technique and I thought I’d share 6 of the best web performance techniques that work every time.

Reduce the size of your images

The most commonly overlooked technique to get a faster website, can not only give you some of the biggest rewards but it’s also the easiest technique to implement.

There are a few areas in which you can reduce the size of your images:

Reducing the aspect ratio
This sounds very obvious but a huge amount of websites I’ve optimised and found that their main banner at the top of every page is 5000 pixels wide but is being displayed at 20% that. Just by reducing that you can save yourself a huge amount of bytes and therefore save your users from a huge download for no real benefit.

Make sure you’re showing the right image for the device
If your customer is viewing your product on their mobile, show them a version of the image that’s no wider than the device. When CSS is used to reduce the size of an image, it’s still the same size to download, just the browser then has to process it to the size required by the CSS, adding more time. Consider looking into srcset which is becoming more widely supported.

Compress the image

Tools like TinyPNGTinyJPG and ImageOptim can save your users from many kilobytes of download without reducing the visual of your image in any way your users will notice. This means that you can save a large amount of bytes on your page, without actually impacting your users. If you can have this built into your media upload, you don’t even need to think about it.

Reduce the ‘quality’ of the image

By reducing the quality of our images, we’re really talking about simplifying the amount of colours being used. This means that we can not only reduce the file size but also making tools like Gzip more effective. Other more advanced techniques of this include reducing the quality significantly to the point where you can see but saving the image at double the resolution, this has been proven to deliver even smaller file sizes without impacting the asset visually.

Remove old and unneeded code

Technical debt is an unavoidable part of any development, making sure you go through and remove old CSS, HTML and JavaScript is hugely important, though.

A few common areas that get overlooked regularly:

Removing vendor files

Pulled out an old version of a carousel or a split testing tool, make sure to pull out the assets as well, that includes the JS and CSS that goes with it.

Removing losing variants of split tests

Very often I’ve seen examples where 2 or more versions of the same element have been created and tested. After this has been analysed and a winner decided, the traffic is pushed down one stream to the winning variant only for the old versions to be forgotten about. Make sure to remove any old code associated with the losing variants of the split test.

Not including the entire framework

This is the most common cause of removing unneeded code, when people include frameworks like Bootstrap or Zurb, they very often include the entire framework, this means all the JS and CSS that build elements that the website might never even use. You can build these files up as and when you need them by not including the unneeded Sass files or only downloading part of the JS. For instance, the entire bootstrap CSS and JS is 668KB whereas the bootstrap grid is just using the grid is 13KB. You can use the customize tool on the Bootstrap website to do this for yourself and tailor the download to your needs.

Prioritise your assets

This is equally as important as anything else, make sure you’re downloading your assets as and when you need them. The simplest case of this is making sure to put your CSS in the head of your file and the JS in the bottom.

Even more than this though we can look at preloading pages and lazy loading.

Preloading

Preloading is when you download an asset before the user requires it and store it in cache or local storage, this means when they get to the area of your website where you think they might need it it’s already available and you don’t have to download it. A good example of when this could work is if you have a booking flow on your website, your booking flow will probably have some extra functionality, so before the user clicks on the search button on your booking engine, you could preload some of this functionality meaning you can load the page quicker and hopefully convert that user.

Lazy loading

Lazy loading is the other side of this, delaying your assets on the page the user is currently looking at until they actually need them. If for instance, you’ve got a gallery on your page, you don’t need to load all of the images the moment the user lands on the page. A more optimal way of doing this would be to download nothing at first, this allows for the first render to happen. Once we’ve displayed the page we download the first couple of images, and maintain being 1 or 2 images ahead of the image in view. This means you’re not downloading images that your user might not ever see but still make your users feel everything is instant as they slide through your gallery.

This is part 1 of a two part series, read part 2 here.

Everything I’ve said about are all web performance techniques that actually work, I’ve implemented them, I’ve seen the results and I can vouch for them.

I’d love to hear your stories implementing some of these results, equally, I’d love to hear some of your web performance techniques that do or don’t work, so please reach out in the comments.