How page speed affects SEO and what you should measure

Thursday, April 26, 2018 | By Chris Rossi
using phone with good website performance for ecommerce

 

“Your website is too slow!”

“Slow? How?”

“I don’t know, it just feels slow.”

We’ve all experienced the frustration of waiting for a painfully slow website to load. Sometimes it’s caused by slow internet, but much of the time it’s the poor performance of the website itself.

Google announced recently that mobile page speed will become a ranking factor in July 2018. With mobile visitors overtaking desktop users in 2014, it’s more important than ever to ensure your website performance is as good as it can be.

 

53% of mobile users will leave a site if it takes over 3 seconds to load.

The average load time for a website is 3.21 seconds (source).

 

Let that sink in for a moment. That means that the average mobile website will lose more than half of its potential customers due to poor performance.

Mobile users in poor coverage areas or with low data caps will also be at a disadvantage. In many cases, your website will simply be inaccessible to them.

But it’s not just about keeping your visitors on the website. A faster site will also inevitably lead to higher conversions, lower bounce rates, decreased bandwidth costs, and happier customers.

 

using phone website performance

 

Interested in learning more about site performance?

This article is the first of a three-part series designed to help you provide a faster experience for your website visitors. Sign up to our newsletter, and we’ll let you know when part 2 and 3 are published!


 

How to troubleshoot website performance

Knowing that your website performance “feels slow” isn’t enough information to help you troubleshoot the problem. To successfully improve performance, you need to target the specific issue that’s causing your website to slow down. The problem could be linked to:

  • The number and size of images
  • The structure and size of your CSS and Javascript files
  • Your website’s dependence on the server for database searches and queries

 

For example, you might try and upgrade your website hosting plan to fix your performance issues. But, if your website has lots of large images or interactive elements, increasing your web hosting plan won’t make any difference.

On the other hand, if your page runs too many database queries, optimising your CSS won’t help.

In order to improve your website performance successfully, we need to measure specific performance metrics to determine where best to focus our efforts.

 

Pagespeed Insights by GoogleA tool like PageSpeed Insights by Google can help you pinpoint any issues.

The performance metrics you should measure

It’s easy to feel overwhelmed by all the dozens of performance metrics available, so let’s break them down to the ones most likely to have a big impact on your website performance. Pass on this reference information to your development or infrastructure team to find out where you might want to spend time streamlining page delivery.

Unless otherwise specified, a lower score is better.

 

website performance

DNS Lookup Time

The first time a visitor tries to access your site, their web browser will need to perform a DNS Lookup to find out which server to connect to. Think of it like looking up a phone number in the telephone book.

As we’ve discussed previously, it’s important to use a fast and reliable DNS provider to minimise the time it takes for your visitors to connect to your web server.

Example: 29 milliseconds

dns_lookup_time

DNS Lookup Time – Time taken to query the DNS records for the domain name

 

SSL Negotiation

Just like DNS, there is an additional overhead when first connecting to a secure SSL-enabled website via HTTPS. Although this can add anywhere from 30-150ms to the load time, an SSL certificate provides additional security and SEO benefits that make it worthwhile. SSL will also boost performance if HTTP/2 is enabled on the server.

(If you are seeing unusually high SSL negotiation times, it may be worth checking for excessive Certificate Chain Length or failed TLS handshakes.)

Example: 130 milliseconds

Time to First Byte (TTFB)

Also known as Backend Time or Server Time.

The Time to First Byte represents the length of time it took for the web server to start sending the HTML document to the visitor’s web browser. For a static HTML site, this should be nearly instantaneous.

For a dynamic site (for example, a site built in PHP, WordPress, Laravel, etc.) it can take longer, depending on a variety of factors.

Some of these factors include:

  • The number of database queries performed
  • Any remote network connections/lookups made by the application
  • Available resources (CPU/Memory) on the server
  • Lack of server-side caching

 

Example: 220 milliseconds

 

first_byte_time

Time to First Byte – Time taken for the server to process the request and send the first byte/bytes back to the browser

 

First Paint Time

The First Paint Time represents how long it takes for the web browser to render pixels to the screen which are different to the previous page.

An example might be the background colour of the page changing from white to grey as the page loads.

A more useful metric is the First Contentful Paint, which represents how long it takes for content to be displayed on the screen. Content could include images, text, navigation menus, or other elements.

Additionally, the First Meaningful Paint tracks the time it takes for useful content to be displayed. An example of useful or meaningful content might be the header text of a blog post, as opposed to the website logo. This can be difficult to measure, as the “Meaningful Content” will vary on every website.

Example: 600 milliseconds 

 

first_paint_time
First Paint Time – Time taken for the web browser to first display something new on the screen

 

Time to Interactive (TTI)

The Time to Interactive(First Interactive) represents how long it takes for the visitor to be able to interact with the page. Most of the User Interface (UI) elements on the page should be interactive at this point. For example, the menu button is visible, but it doesn’t open the navigation when clicked. This means that the page isn’t yet interactive.

Another related metric is the Time to Consistently Interactive, which represents when the page is completely interactive and no longer downloading resources.

Example: 800 milliseconds

 

time_to_interactive

Time to Interactive (TTI) – How long until the visitor can first interact with the page

 

Perceptual Speed Index

The Speed Index is the average time at which visible parts of the page are displayed.

Example: 1100 milliseconds

 

perceptual_speed_index

Perceptual Speed Index – Average time in which visible parts of the page are displayed

 

Page Size

A web page is made up of HTML, stylesheets (CSS), Javascript (JS), and image files (JPG, PNG, GIF, WEBP, etc).

Each of these will increase the size of the page, causing a longer delay for the user as each website asset downloads.

Example:

  • HTML: 50KB
  • CSS: 100KB
  • JS: 80KB
  • Images: 250KB
  • Total: 480KB

 

content_size

Page Size – Total HTML, CSS, JS, and image size of the page

 

 

What does this mean for businesses?

You should now have a good understanding of the different metrics your team should be measuring to track how well your website is performing. By analysing them individually, we can start to recognise why our websites take as long to load as they do. It also shows you where you can improve your website performance to provide a better and faster experience for your visitors.

 

working on website performance

 

Interested in learning more about improving your site performance?

Part two of our series gives you a useful checklist of monitoring tools and tests that will help you to successfully optimise your website performance. Sign up to our newsletter, and we’ll let you know as soon as we publish part two!