Site Speed Optimisation

Your website’s performance is a crucial factor when it comes to providing users with a positive experience. Site (and page) speed is one of the few signals that Google has confirmed as being a ranking factor for both desktop and mobile search.

Simply put, this means that a website that loads faster, will rank higher in the search results.

In this chapter, you will understand why site speed is important and learn how to optimise your website’s load speed in a Google-friendly way.

What is Site Speed?

At its most basic level site speed can be defined as the average time it takes to fully load a page as a mean average across all a website’s pages.

Let’s unpack this statement a little further and take a closer look at what it means for a page to have been “fully” loaded.

A fully loaded page is one where the time between a page being requested by a user and the time that all resources have been rendered on the browser. In other words, there are no more elements of the page left to load.

Site speed is based on the moment your website begins to appear in a browser, which is known as the 90th percentile First Contentful Paint (FCP).

This is backed up by Google’s own definition of site speed:“Site speed reflects how quickly a website responds to web requests”.

The second part of our definition refers to the “average across all website pages”.

In most cases, each web page on a website has varying amounts of unique content. As a result, some pages may have additional resources such as extra images that warrant a longer load time.

Therefore, Google measures “the speed of all the pages that make up your site based on real world data collected via the Chrome User Experience Report (CrUX)”.

The CrUX is a publically available report that is updated monthly with user experience data that is sorted based on country and effective connection type.

Why is Site Speed Important?

Just like how restaurants aim to serve your food as quickly as possible so that diners have an enjoyable experience, presenting users with answers to their search queries quickly is crucial in search.

As we mentioned before, site speed is a ranking factor – a slow website does not only result in poor search engine rankings; hinder the user’s experience and result in fewer organic visits and conversion; it also increases operational costs.

As is the case with any other ranking factors, it’s impossible to quantify its exact importance in the context of Google’s algorithm, but what is clear is that Google’s main priority is to present users with the best possible experience. This means presenting search results that offer what they’re looking for quickly as opposed to ranking a site that users will be frustrated with and click off due to slow load times.

Let’s take a look at site speed from both Google and the user’s perspective.

How Speed Impacts Users

Modern internet users expect results to be delivered to them as quickly as possible. If a website takes too long to load, users do not have the patience to wait and will simply leave.

This is something that is expressed in a patent granted to Google in 2014 titled “Using resource load times in ranking search results”, which states “Given two resources that are of similar relevance to a search query, a typical user may prefer to visit the resource having the shorter load time.”

For users, a faster website correlates with a positive user experience, which increases the likelihood of better conversions. If a user lands on a page from the SERPs, and the page takes too long to load, then it’s highly likely that user will bounce immediately back to the SERPs and visit another web page instead.

This is because users want immediate results for their query and they know that they can nearly always get what they want from another website. Unless your page offers something unique to everyone else, users will show no mercy in bouncing back to the search results page and then to your competition.

How Speed Impacts Google

Google confirmed that page speed plays a part during the ranking phase in the patent, explaining that “a search result for a resource having a short load time relative to resources having longer load times can be promoted in a presentation order, and search results for the resources having longer load times can be demoted”.

However, a slow website also has implications when it comes to how Google interacts with your website during the crawling phase.

Google only has a finite amount of time and capacity to spend time crawling, indexing and rendering a site. Therefore, if a website is too slow to load, then Google may not be able to crawl the entire website – meaning important pages may be missed before Googlebot moves onto the next website.

This is an issue if you have a site that is either constantly growing at scale or is being updated with new content regularly as Google will simply take longer to see these changes. This will impact the rate of indexing by Google meaning that any change made on the site will not be reflected as quickly in the results.

What is Page Speed?

Often confused with site speed (which is the mean average of all pages), page speed refers to the speed of an individual page i.e. the time it takes one page to render fully on a web browser.

There are several visual load metrics that are used to measure page speed:

1. Fully Loaded Page: this refers to the time it takes for all resources on the web page to be rendered and displayed to the user (or user agents).

2. Time to First Bite – this measures the time spent waiting for the initial response from the server to start loading the contents of a web page. It’s the very beginning of the loading process, where the first byted (pieces) of information are sent back to the user by the server after the request has been made.

3. First Contentful Paint (FCP) – this measures the time taken for the web browser to render the first DOM element after the user navigates to your web page.

4. First Meaningful Paint (FMP) – this measures the time taken to load enough of the web pages’ resources so that the user (or search engine bot) can read the content on the page.

5. First Input Delay (FID) – this measures the time between the user interacting with a web page (i.e. clicking a link or tapping a button) to the time when the browser is actually able to respond to that interaction.

6. Average Speed Index – this measures how quickly the contents of the web page is displayed to the user.

Each of these metrics provide an insight into a page’s load speed at various stages of the user’s experience. For example, a low FID entails a fast response time and in turn tells the user that their interactions will be registered and executed quickly whereas a high TTFD results in the user having to wait a long time for the contents of a web page to load.

The above graphic from a Google study wonderfully illustrates a user’s likelihood of leaving a web page as a result of slow load times.

Why is Page Speed Important?

Even if you have good overall site speed you will not rank well for a keyword if the web page that is targeting that keyword is slow.

This is because Google treats each query uniquely, hoping to give the best possible answer for every unique search.

If a website is fast overall but has a painfully slow load time for a page that perfectly matches a query searched on Google, then it will not rank as well as it could.

How Google Evaluates Load Times

The patent we mentioned earlier shines some light as to how Google measures and compares the speed or two different resources as well as outlines which factors impact the load time of a web page in a browser.

Essentially, when given two different web pages for a particular search query, Google may limit itself to testing the speeds using devices that are:

1. In the same country

2. Using the same user-agent (i.e. using the same web browser)

To measure the load times of two different web pages.

Other factors such as the user’s device, the resource that is being requested, the web server that is serving the resource as well as the network connections are also listed as factors that may contribute to variance in load times.

The patent also takes into account how information data on load speeds for some resources may be lacking, which makes it difficult to accurately evaluate the speed. Google provides the following example: “A resource in Chinese may not have enough visits from user devices located in France to generate a meaningful load time measure using solely devices from France, or a newly launched website may not have sufficient load time data associated with its resources”.

The bottom line however, is that if two web pages are being compared and one loads quicker than the other, the quicker result is prioritised in the search results page while the slower page is demoted.

Therefore, although your site speed isn’t as impactful as say the relevance of a web page, it could be the deciding factor when two similarly fast (or slow) pages are pitted against each other.

How Google Measures Load Times

When it comes to measuring load times, Google uses a combination of lab data (i.e. a prediction of the theoretical speed of a web page based on Google’s own testing) and field data (i.e. from users who have tried to access the pages that were tested) – this is according to Google Webmaster Trends Analyst John Mueller.

Mueller also explained how this data is similar to what is contained in the Chrome User Experience Report (CrUX report).

Although there is no “ideal” page speed that Google is looking for, it has provided some thresholds for users to aim for:

Fast: 0 – 1 second
Average: 1 second – 2.5 seconds
Slow: 2.5 seconds and up

Google also recommends that the average speed index is less than 3 seconds and the time to first byte should be no more than 200 milliseconds.

Measuring Site Speed and Page Speed

As we’ve seen, there are several different ways to measure the performance of your website and web pages. There’s no definitive metric that trumps the others as you may end up improving on some metrics while comprising others.

Instead the focus should be on improving the load speeds across all metrics.

How to Measure Site Speed

Measuring site speed is often overlooked and misconstrued by SEOs who direct marketers to tools that actually page speed. You can monitor your site speed performance on Google Analytics by navigating to:

Behaviour > Site Speed > Overview

Here, Google provides an accurate measurement of various metrics pertaining to the average load speeds of your website (i.e. your site speed) over time.

The main metric that is of interest, is the Avg. Page Load Time.

This metric measures the full time it takes on average to render a web page on your website. It’s worth emphasising that this is indeed an average measure and that the individual page load time will vary significantly depending on their content.

Remember, some web pages are more resource-heavy than others.

If you navigate to:

Behaviour > Site Speed > Page Timings

You can view the timings on a page level, allowing you to identify pages that loaded slower than the average page load time of your website.

Google also provides specific suggestions on how to improve the load times for each page.

To view the suggestions, navigate to:

Behaviour > Site Speed > Speed Suggestions

How to Measure Page Speed

As we mentioned before, there is a variety of third party tools available for measuring individual page speeds including crawlers like Sitebulb as well as websites like GTMetrix and Pingdom both of which offer detailed suggestions on how to improve your page speed.

Google also has its own tool called: PageSpeed Insights which allows you to test the performance of a web page on both mobile and desktop.

The PageSpeed Insights tool provides a performance score based upon how well a web page meets a number of rules that are set by Google.

It’s good practice to use all of them as each have their own unique data points of focus that can provide useful information for improving overall performance.

Best Practices for Page Speed

It’s now time to turn the theory into practice.

Below we have highlighted the best practices for improving your website’s loading times.

Server Side Recommendations

Improving Server Load Times

As you may remember from Physics 101:

Speed = Distance / Time

In order to improve speed, these variables need to be considered and adjusted accordingly.

Now that electric signals can travel near the speed of light, it’s very difficult for us to improve on this!

However, distance is something we can control. All other variables being equal, a computer based in the United States should connect and receive information quicker from a Canadian based server as opposed to a UK based server. This reflects the examples Google provided in their patent for comparing page load times.

Based on this, it makes sense to have your website hosted on a server that is closest to your main target audience.

If you have an international audience, then a CDN (content delivery network) like Cloudflare is recommended however more on this in the CDN chapter later on in this module.

Other ways to minimise your server response time include:

Reduce Server Requests

There is a maximum capacity of output before a server begins to compromise its performance. If a web server is being sent too many HTTP requests and/or needs to load and return data that is larger in size than it can handle, it will either dramatically slow down or crash. As a result, minimising the number of server requests that the client makes to the server is an important step to take in improving load times.

This is a common issue with website themes which load several CSS and JavaScript files which require additional HTTP requests to fetch and execute the code. The number of requests can quickly add up if you consider that these themes add additional CSS and JS files as a result of any plugins that you may have installed on top of your own files.

In order to solve this, you should:

Server Configuration

The configuration of your web server is another factor that affects your website’s performance.

Most content management systems (CMS) are based on a PHP framework that is then converted in the HTML. How efficiently the server executes this framework will impact the overall speed performance of this site. This is why different hosting providers advertise their platform as being friendly for WordPress, Magento etc.

When it comes to hosting, using a budget hosting provider is not recommended. This is because you will likely be sharing the same web server as countless other websites which all but guarantees that loading times will be nowhere near as fast as you would like.

There are hundreds of web hosting providers so it’s difficult to recommend just one. However, the main takeaway here, is to consider upgrading to a premium host or if possible, a dedicated server.

Site Wide Recommendations

Browser Caching

Caching refers to the storing of information locally (i.e your browser) in order to help speed up the reloading of an asset like a web page.

For websites, browser caching can be set in the htaccess file and can include instructions on caching different types of content like images, stylesheets, JavaScript, videos and more.

Caching improves performance as when a visitor returns to your website, the browser no longer has to reload the entire page as it has already stored some of the assets from the web page.

You can find more information on how to implement and leverage browser caching from Google here.

Theme

If you are using a CMS (content management system) that provides themes like WordPress, or Bigcommerce we recommend that you conduct some research on what themes have been tested to have the best speed performance for that platform.

Page Level Recommendations

Remove Render Blocking JS and CSS

The source code for a web page should be constructed in the following order:

1. HTML

2. CSS

3. JavaScript

This is because Google is able to render HTML and CSS quickly, but is slow to render Javascript code.

In fact the default version of Googlebot is unable to render Javascript properly and when it discovers JavaScript code it requests another specialised bot to render the scripts.

With that in mind, you should ensure that any CSS and external JavaScript are kept below the HTML code. This is because these scripts must be fetched before they can be executed – in other words, they “block” the bot from rendering anything else.

Use Google’s PageSpeed Insights tool to identify which JavaScript files are blocking the rendering process.

To avoid render-blocking JavaScript, Google recommends inlining scripts to avoid additional network requests.

For example, if you had an HTML page that references an external JS file “file.js” like so:

<html>
  <head>
    <script src="small.js"></script>
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>

You can inline the script within the HTML itself:

<html>
  <head>
    <script>
      /* contents of a small JavaScript file */
    </script>
  </head>
  <body>
    <div>
      Hello, world!
    </div>
  </body>
</html>

This prevents additional server requests being made to fetch and execute the JavaScript.

Note that this is effective for small JS files.

In addition, if CSS or JS code is not needed for a particular page, then it should be removed, made asynchronous or deferred until after the first render to minimise the load times. This is a common issue with some themes/CMS that replicate scripts across all pages when it is not needed.

You can find more information about removing render-blocking JavaScript here.

Compress and Minify Resources

Apart from render-blocking, compressing and minifying resources such as stylesheets and JavaScript files can drastically improve load times.

Both CSS and JS can have hundreds if not thousands of lines of code – most of which may not be necessary at all.

Every single character from spaces and commas to line breaks and comments increases the size of your files.

Whilst well formatted and commented code makes it easier for humans to understand, it makes no difference to the web server and compiler that executes and runs the code.

Therefore, removing such redundant code can help improve your site’s performance.

Here are some tips on how to minify your resources:

There are several tools available that can help speed up the process for you.

Once you have minified your code, you should also compress it using GZip.

Image Optimisation

Images are a common culprit when it comes to slowing down page load times.There are steps however that can be performed to help improve the speed for pages that are image-heavy.

Compression

The raw data size of images should be as small as possible so that the server spends less time loading. Images should be compressed as much as possible before uploading to your website. Remember that big files correlate with increased higher definition images.

In cases where the image quality is important, we recommend using lossless compression.

However, if image quality is not an important factor to the page then lossy compression can be used.

There are a number of WordPress plugins available that automatically compress the images that you upload, we recommend: WordPress Rocket.

For Non WP websites, there are several third party tools that you can use such as TinyPNG. We also recommend using Photoshop for image compression to ensure that you maintain image quality too.

Image Size

Use appropriate image sizes across your web pages.

If for example you display an image on your website that is 500 pixels wide, using a 2000 pixel wide image offers no benefits.

Lazy Loading

Lazy loading is a technique used to defer the loading of resources that are not critical during the loading process. Instead, these non-critical resources are only loaded when they are needed.

This technique is especially useful for mobile pages where you do not want to load images or videos that are not currently displayed on the user’s screen – especially when you consider that users tend to start at the top when landing on a given web page and may even leave before reaching the bottom.

An example of lazy loading is present on the content publishing website Medium.

Medium initially loads placeholder images which are then replaced by lazy-loaded images as the user scrolls down the page in the viewport.

You can find information about implementing lazy loading here.