A site that loads in a second from your office can take four seconds for a visitor on the other side of the world. Distance, the CDN edge that answers, local DNS and region-specific scripts all change what each market experiences, and a single speed test from your own desk shows none of it. If you sell or rank in several countries, testing from those countries is part of SEO monitoring, not an optional extra.
This guide covers how to test website speed from different locations: which tools measure what, why PageSpeed Insights alone is not enough, how to check that your CDN behaves the same in every market, and a simple workflow you can repeat every week.
Why speed changes by country
The same URL is not the same page everywhere. Five things change between markets:
- Distance. Every round trip between visitor and server costs time, and a page needs several of them (DNS, TCP, TLS, then the request). Far-away visitors pay that cost on every one.
- The CDN edge. A CDN answers from the point of presence nearest to the visitor, if it has one in that region. A market served from an edge two countries away behaves very differently from one with a local edge.
- Cache state. Each edge has its own cache. Your home market keeps pages warm; a smaller market may get a cache miss and wait for your origin.
- DNS routing. Geo DNS can send a country to a different origin or a different CDN altogether.
- Region-specific content. Consent banners in Europe, local payment widgets, translated pages and country-specific third-party tags all add weight that your home version never loads.
Google’s Core Web Vitals are measured on real visits, so slow markets pull your field data down even when your own tests look perfect.
Lab data versus field data
There are two kinds of speed data, and you need both.
Field data comes from real Chrome users. PageSpeed Insights and Search Console show it from the Chrome UX Report (CrUX), but only as one global figure for your page or origin. CrUX does publish country-level data in its public BigQuery dataset, which is the most honest answer to “how fast are we in Brazil?”. It is monthly and needs enough traffic from that country to appear.
Lab data is a controlled test run on demand. The Lighthouse test inside PageSpeed Insights runs from a Google data center, not from your visitors’ countries, so its lab score says nothing about the experience in a specific market. Use it to find problems in the page itself, not to compare regions.
For lab tests by location, use a tool with real test agents in many places, such as WebPageTest, where you choose the location, browser and connection speed for each run. Commercial synthetic monitoring services do the same on a schedule.
Test what each country is served
Speed tools tell you how long a page took. They do not always tell you why one country is slower. For that you need to see the response a visitor in that country actually gets: which edge answered, whether it was a cache hit, whether there was an extra redirect, and how heavy the page was.
Requests through residential proxies in the target country show exactly that, because the request arrives from a home connection in that market, the same way a real visitor’s does. CDNs and geo DNS route it as they would route your customers.
A simple check with curl prints the timing breakdown and the headers that matter:
curl -s -o /dev/null -D - \
-x http://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 \
-w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \
https://www.example.com/Change country-de to each market you care about, for example country-br or country-jp, and compare. Look at:
- Cache status headers such as
cf-cache-status,x-cacheorx-vercel-cache.HITin your home market andMISSelsewhere means that edge serves cold pages. - Edge identifiers. Cloudflare’s
cf-rayends in the airport code of the data center that answered; CloudFront sendsx-amz-cf-pop; Fastly sendsx-served-by. If German visitors are answered from another continent, you have found your problem. Age, which shows how long the cached copy has been at that edge.- Redirects and size. A country-specific redirect or a heavier localised page shows up as extra hops and more bytes.
One caution: a proxied request travels through the proxy network as well, so its absolute timings are higher than a local visitor’s. Use proxied tests to compare countries against each other and to see what is served, and take absolute load times from WebPageTest or field data. For a quick visual look at a page from another country without any setup, a free web proxy is enough.
Testing CDN performance and edge caching
Most regional slowness turns out to be a CDN issue rather than a server issue. Run these checks per market:
Edge coverage. Confirm which edge answers each country. Providers publish their point of presence lists, but the only proof is the edge header on a request from inside that country, for example from Germany or Japan.
Cache hit ratio by region. Request the same URL two or three times from each country. The first request may miss; the second should hit. If it keeps missing, the response is probably not cacheable there.
Cache key fragmentation. A Vary header on cookies or user agent, or a geo cookie set on the first visit, can split one page into many cache entries. Small markets then almost never hit a warm copy.
Purge propagation. After a deploy or purge, check from several countries that the new version is served everywhere, not just at the edge closest to you.
Origin shield. If misses are slow in distant markets, an origin shield or regional tiered caching lets edges fetch from a nearby cache instead of your origin.
A repeatable workflow
- Pick your markets from Search Console and analytics: the countries that send traffic or revenue, plus the ones you are trying to grow.
- Check field data per country in the CrUX BigQuery dataset once a month.
- Run lab tests for your key templates from each market in WebPageTest, with the same browser and connection each time.
- Inspect what is served with proxied requests per country: edge, cache status, redirects and size.
- Fix and re-test in the markets where the numbers or the headers look wrong.
The same per-country approach applies to rankings and content. Our guides to geo-grid rank tracking and localisation QA at scale cover those checks.
FAQ
How do I test my website speed from another country?
Use a lab tool with test agents in that country, such as WebPageTest, for load times. To see what that country is served (CDN edge, cache status, redirects), send requests through a residential proxy located there.
Does PageSpeed Insights test from my visitors’ location?
No. Its lab test runs from a Google data center, and its field data is one global figure. Country-level field data is available in the CrUX BigQuery dataset.
Why is my site slower in some countries?
Usually because there is no nearby CDN edge, the edge has a cold cache, geo DNS routes that country to a distant origin, or the localised page loads extra scripts.
How often should I test speed by country?
Weekly synthetic checks on your key templates, a monthly look at field data, and an extra check after every major deploy or CDN change.
The bottom line
Speed is local. Use field data for the truth per country, a multi-location lab tool for comparable load times, and in-country requests to see which edge answers and whether it serves a warm cache. Most regional slowness comes down to the CDN, and it is easy to fix once you can see it from where your visitors are.