How to Measure Real Page Speed for Visitors Around the World

To measure page speed by location you have to run the request from more than one place and compare the timings, because a single test from your own network only tells you how the site behaves for you. The fastest way to start is to fetch the same URL from several regions with a timing breakdown, then read the phases to see whether the delay is connection setup, server response, or transfer.

A plain curl from a machine in each target region gives you that breakdown without any third party service in the path. The variables are built into curl, so you can print them as a small table:

curl -s -o /dev/null -w \
'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/

Run that from a host in each market you care about, several times, and keep the output. The shape of the result looks like this:

dns=0.012 connect=0.048 tls=0.121 ttfb=0.310 total=0.684

Each field maps to a phase. time_namelookup is DNS resolution. time_connect is the TCP handshake. time_appconnect is the TLS handshake, which only appears for HTTPS. time_starttransfer is time to first byte, meaning the moment the server starts sending the response body. time_total is everything, including the body download. Subtract adjacent fields and you get the cost of each phase. If ttfb minus tls is large, the server or the application behind it is slow, not the network. If connect minus dns is large, you are looking at distance and routing.

How to measure page speed by location without owning servers everywhere

Most people do not have a box in every country. The practical substitutes are public measurement endpoints and hosted probes. A number of public services let you request a URL and return timings observed from their own network, and some expose that as a simple HTTP call you can script. Look up a synthetic monitoring provider and check whether its API returns a per location breakdown, because the useful ones separate DNS, connect, TLS and first byte rather than handing you a single number.

If you control a VPS provider with regions, spin up the smallest instance in two or three markets, run the curl loop above, and destroy them. That is the most honest measurement you will get, because you control the client and the network path is a normal consumer or datacenter route rather than a monitoring vendor's optimized backbone. Use a loop so you get a distribution rather than one sample:

for i in $(seq 1 10); do
  curl -s -o /dev/null -w '%{time_connect} %{time_starttransfer} %{time_total}\n' \
    https://example.com/
done

Ten samples per region is enough to see whether the slow result is consistent or a one off. Sort the output and look at the median rather than the best case. A single fast run proves nothing.

Reading the numbers: host versus CDN versus network

The phase breakdown tells you who to blame. DNS time that is high in one region usually means the resolver there is far from your authoritative nameservers or the answer is not cached. You can check what is being returned and from where with dig against a public resolver in that region:

dig +short example.com A
dig +short example.com AAAA
dig +trace example.com

If the address returned differs by region, a CDN or geo DNS is in play and each region is hitting a different edge. If the same address comes back everywhere, every visitor is crossing the ocean to reach one origin, and high connect times in distant markets are expected. That is a routing fact, not a host fault, and the fix is a CDN or a second origin, not a support ticket.

High ttfb with low connect means the network is fine and the server is slow. That is the case where the host is genuinely at fault, or where your application is doing expensive work per request. Compare a static file on the same host against a dynamic page. If the static file is fast everywhere and the dynamic page is slow everywhere, the problem is your code or database, not the hosting.

High total with normal ttfb means the body is large or the connection is being throttled. Check response headers for compression and caching directives:

curl -sI https://example.com/ | grep -iE 'content-encoding|cache-control|vary|age'

If content-encoding is missing, the server is sending uncompressed bytes and every distant visitor pays for it. If cache-control is set to something short or no-store, a CDN in front of you cannot help much because it will not retain the response. The age header, when present, tells you how long an edge has held the object, which is a direct check on whether your CDN configuration is doing what you think.

Making the measurement trustworthy

Control for the things that are not your site. Run each test more than once and discard the first, since DNS and TLS caching change the second run. Test the same URL, not the homepage one time and a deep page the next. Note the client's network, because a probe on a cloud backbone and a probe on mobile data will disagree and both are correct for their own users. Keep the raw output in a file per region so you can compare across changes rather than relying on memory.

For anything beyond a handful of regions, put the measurement on a schedule and store the phase timings. A small script that appends the curl output with a timestamp to a log per region gives you a history, and history is what lets you say whether a host or CDN got slower in a market or whether it was always like this. One test is an anecdote. A week of samples is evidence.

Start with the curl timing line from two regions you care about, run it ten times each, and write down the phase breakdown. If the pattern points at the network, look at DNS answers and caching headers before you change hosts. If it points at time to first byte, profile the application first. Change one thing, rerun the same command from the same places, and compare the numbers.