A speed test measures the trip from wherever its server sits. Many run from the United States by default, so choose a location near your customers, keep it the same each time, and check with a real phone locally.

Two tests, two answers

An owner runs a free speed test on the business website and gets a poor result: the server was slow to respond, the report says, and so was the page.

A salesperson from a hosting company runs a different test the same afternoon and suggests moving the site to a cheaper plan in the United States, which tests faster.

Neither result is false. Both timed a trip from a test computer to the server and back, and both computers sat in a data centre in Virginia, nearly four thousand kilometres from the site's customers.

Where a test runs from changes what it measures. For a business whose customers are in BC, it can change the conclusion entirely.

Where free tests run from

A speed test is a computer somewhere loading your page and timing each step. Free tests keep those computers in data centres, and many of them are in the United States.

Unless you choose otherwise, a test uses its default location, and northern Virginia, home to one of the largest clusters of data centres anywhere, is a common one.

Most tests let you change the location, the browser and the connection speed. Few people do, because the default result arrives first and looks authoritative.

What distance adds

The fifth is worth checking on any site. A visitor sent from the bare domain to the www version and then to HTTPS pays the distance several extra times before the page has even begun.

Why a Canadian site can look slow from Virginia

Each round trip between BC and Virginia takes several hundredths of a second, even on good networks, and a page needs a handful of them before the server's first byte arrives.

So a test in Virginia reports a slow time to first byte for a site hosted in Vancouver, even when the server itself answers quickly. Much of what it measured was the continent.

A visitor in Kamloops never crosses that distance. For them the same server is a few hundred kilometres away, and its first byte arrives sooner.

And a distant site can look fast

The opposite happens too. A site hosted in the eastern United States, close to the test computer, scores well from Virginia because the test barely travels.

Its customers in BC do the travelling instead, on every connection and every redirect, and on a phone over a mobile network each trip is slower again.

That is how a site can pass every test its owner runs and still feel sluggish to the people it is for.

A worked example

A vacation rental management company in the Okanagan looks after about forty holiday homes, and most of its guests book from BC, Alberta and Washington State. Each property has a page of photographs, rates and a booking button.

The owner tested the site with a free tool, saw a slow server response from its default location in Virginia, and came close to moving the site to cheaper hosting in the United States on the strength of it.

Its web company tested again from the west coast and from a phone in Kelowna. The server answered quickly from both. The slow part, from anywhere, was each property page loading thirty full-size photographs before showing anything.

The hosting stayed where it was. The photographs were resized, with the first three loading with the page and the rest as the visitor scrolls.

Every test since has used the same west coast location, so each result can be compared with the last.

Choosing a location

Test from as close to your customers as the tool allows. For a business serving BC, that usually means a location on the west coast of North America.

A business with customers across the country should test from two or three places, and expect the results to differ.

Set the connection to something like a mobile network rather than a fast office line, since that is how many visitors arrive.

Test the same way every time

A single result tells you little. Networks vary from minute to minute, and the same page can test a second slower for no reason at all.

Run each test three times and use the middle result. Keep the location, browser, connection and page the same from one month to the next, and write them down.

Note whether the test is a first visit or a repeat one. A returning visitor's browser already holds most of the files, so the repeat view is usually much faster and flatters the site.

What real visitors experience

A test is a simulation. Your visitors are the real thing, and they can be measured too.

The Site Speed section of Analytics times a sample of real visits and can break the results down by city, so you can see how the site loads in Kelowna rather than in Virginia.

Nothing replaces a real phone, on mobile data, in your own area. Load the main pages, time how long each takes before you can read it and tap something, and repeat it whenever something changes.

The counter-case

A test from far away is not useless. If a real share of your customers are in Ontario or the United States, the distant result describes their experience, and it deserves attention.

A site behind a content delivery network, which keeps copies of files in many cities, depends less on where its main server sits, and tests from different places come closer together.

Some problems also show up from anywhere: a page weighing several megabytes is slow from Kelowna and from Virginia alike.

Still, judge speed from where your customers are, the same way each time, and check the result on a real phone.

The routine

  1. Find where your customers are in Analytics.
  2. Choose the nearest test location offered.
  3. Set a mobile connection speed.
  4. Run each test three times.
  5. Record the settings with the results.
  6. Check the Site Speed figures by city.
  7. Load key pages on a local phone.

Step two is the one that changes the conclusion. The same server can look slow or fast depending on where the test stands, and only one of those places is where your customers live.

What happens on the server before that first byte is covered in server response time before anything loads.


Frequently asked questions

Why does my site test slowly from Virginia?

Because each round trip crosses the continent, and a page needs several before its first byte arrives. Much of what the test measured was distance, not your server.

Should I move hosting to the United States?

Not on the strength of a test run from there. Test from near your customers first; for a BC business, a nearby server usually serves them better.

Which test location should I choose?

The one nearest your customers that the test offers, usually on the west coast for a BC business. Customers across Canada call for testing from two or three places.

Why do results change between runs?

Networks vary from minute to minute. Run each test three times, use the middle result, and keep the location, browser, connection and page the same every time.

How can I see real visitors' speed?

The Site Speed section of Analytics times a sample of real visits and can show results by city. A real phone on mobile data in your area completes the picture.

Is a distant test ever useful?

Yes, when real customers are there. It also catches problems that show up anywhere, such as a page weighing several megabytes, which is slow from every location.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Speed test result that worries you?

Send us the report. We will retest from near your customers and on a real phone, and explain the difference.

Start a Conversation