Global Website Speed Test: How to Check Page Load Speed from Multiple Regions

What does a multi-region speed test actually measure?

Each Latixo test is one controlled browser run from one location that you select. Latixo does not quietly move a job to a different node. Checking a page from multiple regions therefore means running a series of single-location tests. It is not one job that fans out to all eight nodes at the same time.

Each run returns:

• Time to First Byte (TTFB): the navigation timing value at responseStart. It covers everything from the start of navigation until the first byte of the main document arrives, including connection setup on a new connection.
• Total load time: the browser’s loadEventEnd value for that run. It is not a Core Web Vital.
• Page weight: encoded bytes that Chromium reports during the capture window.
• Request count: the network requests observed during the run.
• Protocol and response basics: the negotiated HTTP version, status code and content type of the main document.
• Visual evidence: a WebP screenshot and a WebM Loading Replay of the first viewport.

The standard Website Speed Test does not report LCP, CLS or INP, and it does not produce a Lighthouse score. The exact definitions are in Website Speed Test Metrics. If you need Core Web Vitals specifically, Largest Contentful Paint explains how that metric differs.

Every run starts in a fresh, isolated browser context with service workers blocked. Each result therefore represents a first visit. Performance for a returning visitor with a warm browser cache is outside the scope of the test.

Which test locations should you choose?

Two rules cover most cases. Test from the regions where your visitors are, and include one location close to your origin server as a control.

Latixo currently has no location in India, the Middle East or Africa. If those audiences matter to you, the nearest node is only a rough stand-in. A run from Singapore does not reproduce the network path from Mumbai. For those markets, real-user data is the more reliable source.

The control location matters because it tells you how to read a slow result. If your origin is in Frankfurt, Nuremberg is your near-origin reference. If your origin is in a US East cloud region, use Virginia. Without that reference, a slow result from Sydney could mean “Sydney is far away” or “the server is slow for everyone,” and the numbers alone cannot tell you which.

How do you run a fair cross-region comparison?

• Use the exact same URL every time. Protocol, www and trailing slash all count. A redirect from http to https, or from the apex domain to www, adds a hop that costs more on long paths. Test the final URL unless the redirect itself is what you are investigating.
• Choose one Test Profile and keep it. The Desktop profile uses each node’s native network, so differences between regions show through more directly. The Mobile profile adds a 4× CPU slowdown and a fixed network profile: 1.6 Mbps down, 750 Kbps up, and a minimum latency of 150 ms. Our inference is that when the real round trip is shorter than that 150 ms floor, the emulated latency can dominate. Nearby regions may then look more alike on Mobile than they would on Desktop. Use Desktop to isolate geography. Use Mobile to see how mobile constraints add to the regional cost.
• Run each location more than once. The first run from a region may reach a CDN edge that does not yet have your content cached. Later runs may then be served from the cache that the first run warmed. If run 1 is consistently slower than runs 2 and 3, keep that result. It is a reasonable approximation of what an infrequent visitor in a low-traffic region might experience.
• Run the regions close together in time. One IP address can have only one queued or running job at a time, so a sweep across all eight locations takes a while. Finish it in a single session to limit time-of-day effects. When you compare two deployments, repeat the sweep at a similar time of day.
• Record the results as you go. Completed results are held only briefly on the Browser Node. Latixo is not a monitoring tool with stored history, so copy the numbers into a spreadsheet and save any screenshots you want to keep.
• Change one variable at a time. If you switch CDN settings and image formats in the same release, the regional comparison cannot tell you which change helped.

What should you record for each run?

Summarize each region by its median rather than its best run. A gap of a few tens of milliseconds between two regions can be ordinary run-to-run variance, not a finding.

Which regional differences actually mean something?

Every number in the results is a measurement of that specific run. Every explanation below is an inference, which you confirm by changing one thing and testing again. For the network mechanisms behind these patterns, see Why Website Speed Varies by Location.

TTFB rises with distance while the control location stays fast. The pattern points toward delivery-path costs, although it does not rule out region-dependent application behavior. A common cause is HTML that is not cached at the edge, so every distant request travels back to the origin. What Is a Good TTFB? covers reasonable ranges.

TTFB is high everywhere, including the control. Look at the origin: application work, database queries, queueing or capacity. A CDN in front of an uncacheable page will not remove this delay.

TTFB is similar across regions, but total load time diverges. The main document arrives on time and something after it is slow. Watch the Loading Replay for late images, blocking scripts or a third-party widget that holds up the page in one region. Heavy media makes the problem worse on long paths, as explained in Do Large Images Slow Down a Website?.

Page weight or request count differs between regions. You may not be comparing the same page state. Geo-redirects, localized storefronts, cookie consent banners shown only to European visitors, region-specific ad or analytics tags, and A/B tests can all change what the browser loads. Check the screenshots before you compare any timings.

One region returns an error status or a blank screenshot. Possible causes include WAF or bot-protection rules that challenge data center IP ranges, deliberate geo-blocking, or a dependency that cannot be reached from that location. Beijing results deserve particular care, because cross-border routing and blocked third-party resources can affect both timing and rendering. A single failed run does not prove any of these causes. Repeat the test, then use the replay to see where the page stalls.

The protocol changes by region. Some edge locations may negotiate HTTP/3 while others fall back to HTTP/2. HTTP/2 vs HTTP/3 explains when that difference is likely to matter.

Where does a lab test from eight locations fall short?

Multi-region lab testing is useful for diagnosis and for before-and-after checks. It has limits that are worth stating plainly:

• Browser Nodes run in data centers. Visitors use residential, corporate and mobile networks, and two ISPs in the same city can take very different routes to your server.
• One run captures one moment. Server load, cache state, dynamic content and third-party availability all change over time.
• The Mobile profile is a browser emulation. It does not run on a physical phone with a mobile CPU or a real radio connection.
• Authenticated pages, private destinations and non-standard ports are outside the scope of the test.
• There is no continuous monitoring or alerting. If you need to know when a region degrades, you need a separate monitoring setup.

Field data, such as the Chrome User Experience Report or your own real-user monitoring, answers a different question: what actual visitors experienced across all of those variables. Use lab tests to find and isolate a problem, and field data to confirm whether fixing it changed anything for real users. The full list of measurement limits is on the methodology page.

Frequently asked questions

Can I test all eight locations with one click?

No, not in the current version. Each test runs from the single location you select, and one IP address can have only one job queued or running at a time. Run the locations one after another, ideally in a single session.

How is this different from PageSpeed Insights?

PageSpeed Insights combines a Lighthouse lab run with Chrome UX Report field data, and it does not let you choose where the lab test runs. Latixo lets you choose the location and shows a screenshot and Loading Replay for each run. It does not produce a Lighthouse score or a Core Web Vitals assessment, and its performance grade is a Latixo heuristic. The two tools answer different questions and can be used side by side.

How many runs per location are enough?

Three runs per location is a practical minimum. That is enough to spot a cold-cache first run and an obvious outlier. If the result will drive an infrastructure decision, run more and compare medians.

Can I check a Shopify store from multiple regions?

Yes. The Shopify Speed Test supports the same fixed-location selection and Desktop/Mobile profiles, and adds resource-level diagnostics for the storefront. Run it from each region you care about, as described above.

Should every region be equally fast?

No. Physical distance sets a minimum delay that no optimization can remove. The realistic goal is to keep distance from being compounded by origin round trips, cold caches, extra redirects or slow third parties. A regional gap that matches the distance is expected. A gap much larger than the distance explains is worth investigating.