Website Speed Testing: Correctly measuring your web hosting provider’s speed

Have you seen any website speed testing reports lately? It’s not that easy to read. The speed of a website can refer to many different things and the measurement is usually fraught with ambiguities and interpretation errors. In this article, we will clear up some confusing aspects of website speed measurement. Then we will help you decipher the speed measure report. Lastly, we will analyze what metrics you need to consider when measuring your web hosting provider’s speed. 

We will be using Pingdom’s WebSite Speed Test tool for our examples. There are many similar tools out there like Dareboost and WebPageTest, and we encourage you to try out all of them in order to get a more balanced result. There is also GTMetrix page load speed and Google’s Page Speed Insights. With Google, well, you have the authority that a Google tool has. On the downside, you won’t get any information about the actual response times (in milliseconds) for your website. So if you are after quantitative results, you will need to check the other tools.

But the truth of the matter is that speed measuring is a bit hard. Let’s clear up some things first.

Measuring website speed is …complicated

Reports from online website speed measuring tools usually deliver an overwhelming amount of information regarding the speed of your website. This is difficult to make sense of, especially if you haven’t used one before. Firstly, there are a couple of points you need to have in mind:

1. Website speed reports give you a total speed mark by combining several widely different metrics together. This gives an overall approximation of how “fast” a website is. However, when you need to assess the speed of a web hosting provider, you will need to take a closer look at the results.
2. Merely running a website speed test once does not give you a realistic view. You will need to execute at least 10 different tests (using the same tool and from the same region) and then compute the average by dividing the results accordingly.
3. Online web page speed tools usually bypass any caching mechanisms that your provider or website might have in place. For example, inspecting the request headers of any request reveals two HTTP headers that disable caching. For this, you should always have caching in mind while you are conducting your tests.

Web provider speed is different from application speed!

Website speed testing tools usually test the same things and display similar types of data. As we mentioned previously, not all of that data actually refers to your provider’s speed. For example, assets that are retrieved from third-party servers like Youtube, do not tell you anything about your provider’s speed. This is because the content resides on different servers, and not on your.

Similarly, Javascript and CSS code metrics only show you how fast your web page will be rendered in the browser.

There are some metrics, however, that do reflect your provider’s speed. These are DNS, the time it takes for your web browser to connect to your web page and get the results, and a number of other metrics. Let’s see them one by one!

Web hosting provider speed metrics

DNS Response time

This metric measures the time it takes for your website’s nameserver to return to your browser the IP address, as measured by the PingDom tool. In general, values below 300ms are considered normal.

If you observe high values in this metric, you may need to start troubleshooting why that’s the case. Ultimately, you might choose to change your DNS provider. Of course, if your DNS records are maintained by your web hosting provider, you will need to take the DNS metric into account.

Connect response time

This response time measures the time it takes for your browser to first connect to your website. This is a metric you obviously need to take into account.

SSL

In the previous screenshot, we saw that there is a redirect to an HTTPS URL happening (visible in the icon on the top left). Pingdom measures the time it takes for the SSL handshake to take place. SSL handshakes are computationally intense operations. Their response times generally depend on various factors such as what protocol is used, whether techniques such as SSL offloading are present, etc.

You will need to take SSL response times into account, only if you are certain that the SSL handshaking is done by your provider. If you are not certain, leave that metric out.

The Send metric is the time it takes for the web browser to send the request to the server. This is related to the Internet connection of your visitor only, and not your website, or your hosting provider. So leave that metric out as well.

Wait/Receive 

These response times indicate the time it takes for your browser to receive the actual webpage. The Wait time is the amount of time your browser waits until the server starts sending data. The Receive time indicates how much time it takes the server to actually send that data to the browser.

Since both these response times are related to the web server, you must take them both into account.

Static assets

The response times for files that are locally served from your website also need to be included. These are called static assets and are usually images, CSS files, and generally anything that is served from your domain.

Modern web browsers accelerate the downloading of resources by using parallel threads of execution and other techniques. For example, if you have a website with 100 requests,  these 100 requests will be downloaded in parallel. Internet Explorer 10 uses a maximum of 8 parallel connections, while Chrome uses 6. Firefox3 and Safari 5 use 6 as well. This value is configurable, but you can easily bring your computer to a grind if you misuse it, so it’s better to leave it as it is. Additionally, HTTP/2 helps significantly when it comes to downloading acceleration since it features a superior packet streaming management than its predecessor.

Finally, identifying your local assets is easy with Pingdom. You can filter results and display the requests for local assets by typing your website domain in the Filter field.

Should you find that there is a significant delay when fetching local assets (particularly images and videos) then think about using a Content Delivery Network (CDN).

With a Content Delivery Network, you can minimize packet loss and latency. CDN services place servers around the globe, so as to bring your content as close as possible to your visitors, thereby reducing latency.

In closing

Website speed measurement tools provide you with a lot of information that you must critically assess, depending on what are you planning to measure.

Summarising then, before you start speed testing your website, have the following in mind:

1. Web hosting speed and the way it is measured are completely different than page load speed.
2. The main metrics you need to pay attention to are Connect/Wait/Receive response times, as well as those of static assets. DNS and SSL are only taken into account if they are managed by your web hosting provider.
3. Leave out all metrics concerning the content that is pulled from third-party services, like Youtube.
4.  Run the test multiple times (at least 10) and then compute the average by dividing the results by the number of tests.

Since the topic of application and page rendering speed is yet another topic of critical importance, we are planning on dedicating a separate article to that. It is also much more complex than measuring web hosting speed since it depends on many factors, and hides quite a few gotchas as well!