How To Compare Web Hosting Speed with


Hey there! Some links on this page may be affiliate links which means that, if you choose to make a purchase, I may earn a small commission at no extra cost to you. I greatly appreciate your support!

In this tutorial, I’ll walk you through the process of measuring site speed for different hosting providers. Learn exactly how I compare web hosting speed of various website hosts with the open source suite of page speed tools from

Testing Page Speed with

First and foremost, I find to be the best way to consistently and systematically measure web hosting speed. Over the years, I’ve tried many different page speed testing tools such as:

While all these are great tools for measuring performance of a website, the one problem is that you can’t automate tests.

As a software engineer, I wasn’t intimidated by running a few commands in terminal (and neither should you). The tools from allow you to automatically run a series of page speed tests.

In fact, is extremely simple to use as there’s pretty much just one command you need to know. We’ll get into this more in a bit.

What’s important to know is that runs the same tests as the tools above, but allows you to do so in an automated manner.

Getting Started with

To get started, make sure you have docker installed.

curl -fsSL -o

Then simply run your first test as the installation guide points out. You can run the tests from your local computer, but I personally ran my tests from a VPS server like Linode.

docker run --rm -v "$(pwd)":/ sitespeedio/ -b firefox

This basic example tests from a FireFox web browser. Test results are generated as HTML pages and stored in a local directory on your computer. Here’s an example of what test results look like.

Configuring Test Settings

Now that you know how to run a basic test with, let’s figure out how we can configure it to compare web hosting speed. I’m going to walk you through the steps I took to compare site speed of Vultr, Linode, and DigitalOcean.

Specify Web Hosts to Test

First, make a file called urls.txt. For me, this file has three lines:  one line for each web host that we want to test. Each line has the full URL of the page to test followed by a space and finally a human readable name for the website. Linode Vultr DigitalOcean

To be clear, in this example is a WordPress website running on a Linode server, is a running on Vultr, and is on DigitalOcean.

You can, of course, perform these tests without domain names and use IP addresses instead, but since I wanted to have DNS lookup times as part of this test.

Configure Page Speed Test Settings

Next, create a file called config.json in the same directory. This file specifies certain settings for running our tests.

  "browsertime": {
    "iterations": 100,
    "cacheClearRaw": true,
    "visualMetrics": false,
    "video": false,
    "browser": "chrome"
  "html": {
    "pageSummaryMetrics": [

As you can probably figure out from the JSON settings, the test will be performed 100 times from a Chrome browser. We don’t care about recording any videos, but we do explicitly clear cache between each test. Here’s what each setting in the browsertime block does.

  • iterations: run the test 100 times
  • cacheClearRaw: clear cache between each iteration test
  • visualMetrics: don’t calculate visual metrics like speed index
  • video: disable recording video
  • browser: use the Google Chrome browser

Within the pageSummaryMetrics block, we specify the speed measurements that we care about.

  • timings.serverResponseTime: The time it takes for the server to send the response
  • timings.backEndTime: The time it takes for the network and the server to generate and start sending the HTML i.e. time to first byte (TTFB)
  • timings.firstPaint: The time it takes the first paint happens on the screen
  • timings.pageLoadTime: The time it takes for page to load
    timings.fullyLoaded: The time when all assets in the page is downloaded

There are dozens and dozens of configuration options which is quite exciting, but perhaps intimidating too. For starters, I recommend sticking to the options above.

Compare Web Hosting Speed Test

Now that we have everything configured to our liking, we can finally run our web hosting speed test! Change the value of name to your liking and issue the following command.

docker run --rm -v "$(pwd)":/ sitespeedio/ --config config.json --name "VPS Web Hosting Speed Comparison" urls.txt

Based on our config.json settings, 100 speed tests will automatically run for each one of the three URLs that we specified in the urls.txt file.

After the test concludes, you can open the directory and find a series of HTML pages that you can browse through like this.

Heads up! You need to understand that the only usable page for our purposes is the Pages tab. You see, the Summary and Detailed Summary pages average out the timings across all web hosts, so the results really don’t make sense.

Instead of specifying urls.txt, we could also specify the domain name directly in the docker command. This way, the results wouldn’t have been combined from each web host, but we’d have to execute three separate tests in this case. The only reason I chose to do it this way was because I really liked the output table on the Pages tab that has the side-by-side comparison table. test resultsPin

Anyway, the possibilities are endless as to how you can configure your page speed tests. I encourage you to play around with it so it meets your needs.

Let me know in the comments below if anything in this tutorial is unclear. A mission of mine with this website is to help you with your web hosting, so don’t hesitate to ask.

Check out the results of my VPS web hosting comparison test here, and how DreamHost, Namecheap, and Bluehost faired out in my shared hosting comparison here.

Meet Tony

With a strong software engineering background, Tony is determined to demystify the web. Discover why Tony quit his job to pursue this mission. You can join the Tony Teaches Tech community here.

Leave a Comment

The reCAPTCHA verification period has expired. Please reload the page.