Why your site scores differently in another country

Three things make a page score differently in another country. The network path is longer. The local devices and connections are slower. Or the page you measure abroad is not the page you measure at home.

Almost every article on this subject covers the first two and stops. We ran 2,800 Lighthouse runs from seven countries to look at the third, and it turned out to be the largest effect we measured.

Start with the network, then rule it out

Distance is the obvious cause and it's usually a real one. A request to a distant origin takes more round trips, so TTFBHow long the browser waited before the first byte of the response arrived. rises and everything after it moves too. A CDNA network of edge servers that serve your content from near the visitor. shortens that path for cached files.

The second cause is the market, not your server. Devices and connections differ by country, and a lab test from a datacenter won't show you that at all. It measures a datacenter's network and a fixed CPU profile. Field data from real visitors is the only thing that captures the device your customers actually hold.

So check the network first, with a metric that responds to distance. LCPTime until the largest thing in view (hero image, headline) has painted. is the useful one. If LCP climbs in the far region, you have a network problem and the standard advice applies.

The interesting case is when LCP doesn't move.

Wikipedia scores 38 points lower from Brazil

We measured en.wikipedia.org/wiki/Lighthouse 100 times from each of seven regions, on mobile, with one pinned Lighthouse version. The performance score from São Paulo averaged 48.5. From Los Angeles it averaged 86.9.

Read the LCP column. Tokyo is slow the way distance makes a page slow — LCP nearly doubles. São Paulo isn't. Its LCP of 2760 ms is the fastest number in that column after Los Angeles, and the two are within 20 ms of each other.

The gap sits entirely in TBTHow long the main thread was busy and couldn’t respond to taps or clicks., which carries 30 percent of the performance score. São Paulo blocks the main thread for about four times as long.

It isn't a slow machine either. Our Johannesburg worker records a lower CPU benchmark than our São Paulo worker, and a third of the blocking time.

What the request list shows

Metrics tell you a page was slower. The request list tells you why. We keep the full JSON report for every run, so we opened one run from each region and compared them.

São Paulo made eight requests that Los Angeles never made. Seven of them name the cause:

meta.wikimedia.org/w/index.php
en.wikipedia.org/beacon/impression
upload.wikimedia.org/wikipedia/donate/…/Charity-navigator.png
upload.wikimedia.org/wikipedia/donate/…/Candid-seal-platinum-2025.svg
upload.wikimedia.org/wikipedia/donate/…/Trustly_logos_only.png
upload.wikimedia.org/wikipedia/donate/…/PSE_logo.png
upload.wikimedia.org/wikipedia/donate/…/Frb-Lisa_Seitz-Gruwell.jpg

That's the Wikimedia fundraising banner. It's delivered by CentralNotice, which targets banners by country using the visitor's IP address. Only the selected countries see them. Brazil was selected on the day we measured, and the United States wasn't.

The banner costs 42 requests instead of 34, and 816 KB instead of 554 KB. It adds 76 KB of JavaScript. On that single pair of runs, Total Blocking Time went from 346 ms to 1197 ms.

This is not a fluke of one run. Across all 200 runs, the two distributions never touch: the slowest São Paulo run still blocked longer than the fastest Los Angeles run.

Run-to-run noise looks like two clouds that overlap. This looks like two different pages, because that's what it is.

Shopify, in reverse: Frankfurt is the fastest region

The same effect can run the other way. We measured shopify.com from the same seven regions. Frankfurt got the best score of the seven, at 44.4.

Frankfurt was also the only region that never loaded these hosts:

connect.facebook.net
www.googletagmanager.com
gtm.shopify.com
snap.licdn.com

Those are marketing and analytics tags. On the pair of runs we opened, Frankfurt fetched 81 requests against Sydney's 144, and 368 KB of script against 955 KB. Mean blocking time across 100 runs each was 1524 ms in Frankfurt and 6311 ms in Sydney.

Shopify documents the mechanism itself. Its Customer Privacy API says that regions configured to require consent block non-essential processing by default. Other regions allow it by default. Europe is a consent region.

We didn't inspect Shopify's own configuration. Treat this as the likely explanation, not a confirmed one.

The direction is worth sitting with. The usual claim is that consent banners make European pages slower. In this measurement the consent regime made the European page much faster, because the Third partyCode and assets loaded from another origin — analytics, fonts, ads, widgets. tags never ran.

How do you tell the three causes apart?

You can do this with two reports and no special tooling.

1. Compare LCP between the fast region and the slow one. If LCP rises with distance, it's the network. Fix the origin path or put a CDN in front.
2. If LCP matches but the score doesn't, compare Total Blocking Time. A large gap there means main-thread work, not distance.
3. Open the request list in both JSON reports. Sort by host. Anything present in one region and absent in the other is your answer.

Step three is the one people skip, and it's the only step that can find a banner.

What this means if you test from one place

Every tool in this category will happily tell you a number for your site. That number describes the version of your site that was served to the machine that ran the test.

I think this is the part the genre gets wrong. Tables of "average load time by country" are published constantly, and they attribute every gap to infrastructure. Some of those gaps are a fundraising banner, a consent regime, or a locale bundle. From one location you can't tell the difference, because you only ever see one version.

If you sell in several markets, measure from several markets. Then compare the request lists, not only the scores.

What we can't tell you

We measured four pages from seven regions. That's enough to show the effect exists and to prove these two cases. It's not enough to say how common it is.

Two limits matter for reading the numbers above. We have one European region, so "Europe" here means Frankfurt. We have no region in India, which is a large market this data says nothing about.

Our runs use Lighthouse 12.8.2 with simulated throttling on a pinned mobile profile. A request list is a direct observation, so the banner and the missing tags don't depend on that choice. The millisecond values do, and another throttling profile would move them.

The full dataset is in the repository, and every number above comes from it.