Server Locations

DebugBear runs lab tests form different locations across the world. The further away your server is from the test device or user device the higher your network round trip times will be and your website will take longer to load.

The real user metrics from the Chrome User Experience Report (CrUX) shows worldwide traffic.

What test locations are available on DebugBear?

DebugBear can monitor your website from the following locations:

Country	Region		Country	Region
🇦🇺 Australia	Sydney		🇵🇱 Poland	Warsaw
🇧🇷 Brazil	Sao Paulo		🇸🇬 Singapore	Singapore
🇨🇦 Canada	Montreal		🇪🇸 Spain	Madrid
🇩🇪 Germany	Frankfurt		🇨🇭 Switzerland	Zurich
🇫🇮 Finland	Hamina		🇹🇼 Taiwan	Changhua
🇫🇷 France	Paris		🇬🇧 UK	London
🇳🇱 Netherlands	Eemshaven		🇺🇸 US East	South Carolina
🇮🇳 India	Mumbai		🇺🇸 US Central	Iowa
🇮🇱 Israel	Tel Aviv		🇺🇸 US West OR	Oregon
🇶🇦 Qatar	Doha		🇺🇸 US West CA	California
🇿🇦 South Africa	Johannesburg
🇮🇹 Italy	Milan
🇯🇵 Japan	Tokyo

What do I do if you don't have a test location in my country?

If we don't have servers in your country you can pick a nearby test location.

For example, we don't have a test location in Mexico. But the ping time between Mexico City and our US Central test location in Iowa is on only about 41 milliseconds. A test location in your country likely would also have about 10 milliseconds of ping time, so using this location adds about 30 milliseconds of round trip time.

The default mobile network latency that's added by PageSpeed Insights and DebugBear to run the performance test is 150 milliseconds. Compared to that the ping time between the servers isn't that significant.

Lab data will never exactly match real user data, you can mostly use it to analyze website performance and track relative changes over time.

You could also reduce latency on the test device to match a test in your region more closely.

Server IP addresses

You can enable fixed IP addresses in your account settings.

How does server location affect performance?

The farther the test server or your users are from the server that hosts your website, the longer it will take to load your site.

For example, let's assume you host your website is hosted in New York and the user is in London. One request round trip from London to New York takes around 70ms. Establishing a connection to your server usually requires 3 round trips, so in the ideal case it would take 210ms to load your page.

The ping time for Sydney to New York is ~270ms, so a user in Sydney would have to wait at least 810ms for your page to load. Your site will show different performance characteristics depending on where your users are.

These are optimistic assumptions that assume a single request is all it takes to load your site. They also don't consider that, on a 3G connection, each roundtrip requires another ~150ms.

To solve this, host your website near where your users are. That's easy if they are all in one place, but harder if they are scattered around the world.

It might not be viable to host your application server in multiple locations, but one easy step to improve performance is using a globally distributed Content Delivery Network (CDN).

These servers can host static content like images, CSS, and JavaScript files. Instead of serving content from one central location CDNs can provide hundreds of server locations around the world and route your user's request to the closest server.

What locations are PageSpeed Insights test run from?

Depending on where the test is run from, PageSpeed Insights uses one of four test locations:

• Northwestern US (Oregon)
• Southeastern US (South Carolina)
• Northwestern Europe (Netherlands)
• Asia (Taiwan)

Hardware differences between test locations

Sometimes different data centers use different hardware to run tests. For example, test devices might use a different CPU. In those cases you might see a difference in CPU time for the same website tested in different locations.

Some of our test locations use faster CPUs – these are marked with the Fast CPU tag.