Why is webpage speed important?

Webpage load time is super important as user expectations on the web grow. To put this into numbers, 53% of users will move away from your site if it doesn’t load within 3 seconds. When looking at mobile, we see that a 1 second load time improvement can increase conversions by 27%. Quick websites are typically smaller in size, which means that mobile users can use your site cheaply, without incurring extra data costs. Doesn’t sound too important? Even in developed countries such as Canada, 2GB of mobile data can cost as much as 30 euros.

Faster sites can rank higher in search engines too.

 

How is website speed recorded?

Time to get technical. There are a number of metrics used to measure webpage speed:

  1. Load Time – The time from pressing enter in your browser’s URL bar until the window load event (onload)
  2. First Byte (TTFB) – First Byte or Time To First Byte is the time from pressing enter in your browser’s URL bar until the first byte of the webpage is received by the browser.
  3. Start Render – The time from pressing enter in your browser’s URL bar until things start to appear in the browser
  4. Visually Complete – The time from pressing enter in your browser’s URL bar until things have finished loading in your browser
  5. Speed Index – The time from pressing enter in your browser’s URL bar until the user feels like the website is usable

Don’t worry, the above is confusing and each measurement is used for different things. If you remember just one, it should be speed index. Speed Index is a user focussed measurement which keeps the importance of user experience in sight. While the others are useful, e.g. TTFB can be used if your web server is slow, they all fold up into speed index eventually. Further to this, if your site is usable in 0.5 seconds but loads extra content (off of the screen) for a further 20 seconds, then your Visual Complete time of 20.5 seconds is pretty useless.

TLDR – focus on speed index time because it measures when your site becomes usable.

 

Front end vs Back end performance

Something often missed is the area of measurement and optimisation. In the traditional web model, you typically have a front end and a back end to any application. Both of these can be optimised. As an example, you have a Java Server Pages website which uses CSS, JavaScript and HTML to display pages. With this stack, you can optimise the Java backend, and measure things like GCC and Memory heap and you can also measure things like image size, css compression on the front end.

This post is focussed on optimising the front end, since these are more general web principles and are often ‘low hanging fruit’ for easy wins.

 

How to measure website speed

There are a couple of great, free, website page speed tools for you to use:

  1. Google Page Speed Insights – This tool is really great for giving you suggestions on what to fix and how. The tool gives you a score out of 100 and shows you steps to take in a really nice interface. It will also compress your assets (images, css, javascript) for you – nice!
  2. Web Page Test – This tool is a little more advanced and is typically used for a more involved look at performance. It allows you to run a test against your site in various browsers and offers you a detailed graph view of each resource (file) on your website. This is super useful for investigating deeper issues and tracking changes over time. There is a Web Page Test API and server module which can be used to automate tests and trigger alerts if slowdowns are detected. This tool also reports on all 5 of the metrics mentioned above.

How can I speed up my site?

Now we understand why page speed is important, what measurements are used and how to perform tests, let’s take a look at some typically easy ways to speed up your site. Don’t forget to run a test first so that we can go back and measure the improvement!

  1. Reduce image size

By far the most common contributor to slow websites are the images on the site. There are a number of ways to optimise these:

  1. Run your website through the Google Page Speed Insight test and it will generate a folder filled with optimised images. These will be reduced in filesize by resizing, removing meta data and reducing quality (to a level which is unnoticable by the human eye).
  2. If your site has a lot of images and they are not all immediately visible by the user (i.e. they have to scroll or perform an action to see them), then consider using Lazy Loading. How to Lazy Load images.
  1. Install GZip

GZip is a compression tool used widely on the web to make your website smaller. This means that the same site uses less bytes, therefore loading quicker and using less mobile data. It is super easy to turn on/install depending on your setup, just Google it 🙂

  1. Async or defer JavaScript

JavaScript is render blocking, which means that, while the file is being read, nothing else on the page will be loaded. So, if you have lots of JavaScript files in the head of your page, this can drastically slow down the load time. There are a couple of easy fixes for this:

    1. For scripts which don’t rely on load order and do not use document.write, they could be loaded asynchrnously by adding the async attribute:

<script async src="my.js">

    1. Add the defer attribute to any JavaScript files which aren’t required until the page is fully loaded:

<script defer src="my.js">

  1. loadCSS / inline CSS

CSS, like JS is render blocking – meaning that, until the CSSOM (yes, who know that was a thing?) is loaded, no other content will be loaded. There are a couple of ways around this:

  1. Use inline styles to paint the content which is viewable to the user (aso known as the above fold content). E.g. the header and the first set of images. <style> .header { height: 300px; } </style>. This works because inline CSS is not render blocking.
  2. Did that make you shudder a little bit? Ok, using inline style tags may be too against the grain for you (but check out amazon and google before you completely discount it) – luckily there is an alternative. The loadCSS plugin allows you to load your CSS asynchronously, just like javascript above.
  1. Turn on caching

    1. Caching is a great way to reduce subsequent load time (i.e. if you have visited the site before, it will load quicker the second time). Caching tells your browser to keep certain resources locally for a while, so that it doesn’t need to download them every time you visit a page. Setup varies but is usually as simple as adding a few lines to your server’s .htaccess file:

## EXPIRES CACHING ##
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
## EXPIRES CACHING ##

Now your site is much quicker!

We’ve picked all the low hanging fruit, so now it is time to run your site through Google Page Speed or Web Page Speed and see how much quicker it is! Don’t forget to measure any changes in user traffic, time on site and conversion too.