Recently, we have been working hard to minimise site speeds for our clients. Discover the quick wins we've uncovered!
Any web developer will know there is a constant wrestle with websites, to get the time at which users can interact properly with a website down as low as possible.
Here are a few quick wins and other interesting things we have found along the way...
The first thing to note is that most of the time, what people report as a website’s speed is not really what matters.
Most people talk in terms of the “Fully Loaded time”. In fact, what matters is the “Onload time”. This is because if a website is setup correctly, then the point at which it is properly usable will be different from when all available resources have fully loaded.
It is “Onload” that Google cares about. This is the figure which we need to seek to get to below 2 seconds on desktop, and ideally 2.4 seconds on mobile.
To give you an example of how these can differ substantially, here is a snapshot of one of our sites before we started working on site speed:
If you were to take this at face value you could be forgiven for thinking this a very slow site. In fact, if we delve a little deeper into what makes up the site speed, we see:
So, on this occasion, the speed that Google would care about is only 3.4s. Quite a difference!
But why is there such a discrepancy between fully loaded time and onload? This is our first quick win!
QUICK WIN #1
It is a great idea to look at the waterfall and see how your site speed is made up. More often than not, the reason is tracking scripts. With modern websites setup for a digital marketing strategy, the core website is only half the problem.
Keen digital marketers often pack their websites full of tracking scripts to monitor website performance, usually without any care for the fact that adding the tracking script in the first place hampers site speed, and in turn performance.
If a tracking script is setup correctly, then it will load asynchronously and therefore load after Google’s onload metric. In this example, the true site speed was 3.4 seconds and the time after up to the fully loaded time of 22 seconds was due to correctly set up tracking scripts.
In fact, this was a spike and due to an unusually slow response from a Facebook script at that time. On that occasion, the user would have been none the wiser.
So what do we advise?
Perform an audit of your tracking scripts. Usually they are served from Tag Manager, so it is easy enough to do.
We have found in many cases that around 50% of tracking scripts being loaded are no longer required and were useful for a temporary trial of some tech or other. No one remembered to remove the tracking script though! If it was asynchronous, it may not matter, however, we have found that even asynchronous scripts leave a footprint which gets loaded as part of the Onload metric.
Below is a graph showing site speed over a month:
On April 12th, we removed unused tracking scripts and saved nearly 2 seconds from the true Onload time.
QUICK WIN 2 - What next? Fix your video!
We all know that video is a great marketing tool.
We also might imagine that serving your video from YouTube, Vimeo, Wistia, Vidyard etc should speed things up right? Well what you may not know is that even though your video may not be loaded until it is clicked on, the website still has to load all the 3rd party machinery necessary to play that video.
We have a solution to this. With a subtle change to the iframe that loads the video, you can force the page not to load the video until it is needed. In the graph above we did this on April 19th saving a further second from the load speed. Now this site has a fully loaded time of 2.6s.
...and an onload of 1.2 seconds:
Once these quick wins have been dealt with you may well have reached your 2 second Holy Grail. If not, well there are plenty more things to do!
At ClickThrough Marketing, we live and breathe site speed. Speak to us about a site speed audit and see how we can help you...