Do Lighthouse scores change when you test from a different region?

Yes, but almost never for the reason people expect. Lighthouse measures the real round trip to every origin on your page. Then, under its default throttling, it throws most of that measurement away and replays the load at a fixed 150 ms.

We ran one page from seven regions to see how much survives. The measured round trip went from 2.5 ms to 275 ms. The performance score stayed at 100.

What moves instead is the latency gap between your origins, and what each region's server chooses to send back.

What seven regions did to one page

The page is lightscore.dev itself. It's a good subject because it's dull: one origin, one server in Germany, no CDNA network of edge servers that serve your content from near the visitor., almost no JavaScript. If distance alone moves a Lighthouse score, this is the page to see it on.

Twelve mobile runs on 13 August 2026, all on Lighthouse 12.8.2. Each far region ran next to a Frankfurt control, so Frankfurt was measured five times. Its round trip came out between 1.2 ms and 2.5 ms. The chart uses the run paired with Sydney.

Six of the seven regions returned a performance score of 100. Tokyo returned 98. Largest Contentful PaintTime until the largest thing in view (hero image, headline) has painted. stayed between 871 ms and 987 ms everywhere, and Sydney's was lower than Frankfurt's.

Why doesn't the distance show up in LCP?

Because Lighthouse deliberately removes it. Simulated throttling is the default, in the CLI and in PageSpeed Insights alike. Chrome loads the page at full speed and records a trace. Lantern, the simulator, then replays that trace against a modelled connection: 150 ms round trip, 1.6 Mbps, 4× CPU slowdown.

That 150 ms is a constant. It doesn't come from the machine that ran the test.

Lighthouse still measures the real round trip per origin, and it still uses part of it. It keeps the excess — how much slower each origin is than the fastest one on the page. Google's own comment in NetworkAnalyzer says why:

We'll use the minimum RTT as the assumed connection latency since we care about how much addt'l latency each origin introduces as Lantern will be simulating with its own connection latency.

A single-origin page has no excess to keep. The fastest origin is the only origin, so the subtraction leaves zero, and the whole 275 ms from Sydney disappears. Lighthouse reported it under network-rtt and then simulated as if it weren't there. That's the flat LCP line in the chart.

Then why did Speed Index move?

Speed Index is the one metric that carries real network distance into a simulated run. Lighthouse blends two estimates for it. The comment above the coefficients is blunt about the first:

Note that the optimistic estimate is based on the real observed speed index rather than a real lantern graph

That observed value comes from the unthrottled load — the one that really did cross the Pacific. At the default 150 ms setting it carries a weight of 1.4.

So Speed Index went from 949 ms in Frankfurt to 2,242 ms in Sydney, a factor of 2.4, while LCP, First Contentful Paint and Time to Interactive all held still. On a page that scores 100 it costs nothing. On a page nearer a scoring threshold it's the metric to watch.

When does the region change the score?

When it changes the gap between origins, or changes what the server sends. We ran the same Frankfurt-versus-Sydney pair against two more sites: one with a slow second origin, one entirely on a CDN.

Wikipedia lost 14 points, and it isn't noise: the two machines benchmarked within 4 percent of each other. A redirect sends wikipedia.org to www.wikipedia.org, so the page has two origins. From Frankfurt both answered in single-digit milliseconds. From Sydney the redirect origin took 203 ms and the second one still answered in under a millisecond. That left 202 ms of excess for the simulation to keep, and LCP moved from 2,231 ms to 3,032 ms. A different Wikimedia IP answered each run, which is the other half of the story.

Vercel is the opposite case. All four of its origins sit on a CDNA network of edge servers that serve your content from near the visitor., every one answered in under 4 ms from both regions, and the score didn't care.

So a region is worth testing from when one of these is true:

• A second origin that isn't on a CDN. Fonts, an API host, a Third partyCode and assets loaded from another origin — analytics, fonts, ads, widgets. tag. The excess over your fastest origin is what the simulation keeps.
• Geo-routed content. A different edge, a different consent banner, a different IP answering. Lighthouse can only score what it was served.
• The machine. Across our twelve runs the CPU benchmark ranged from 745 to 1,898. Change the region and you change the hardware too.

Can I choose the region in PageSpeed Insights?

No. Google's documentation states that PageSpeed Insights "runs in a Google datacenter that can vary based on network conditions". It reports North America, Europe or Asia after the run, so you learn which one you got rather than pick it.

Someone asked for a dropdown in 2020. A Lighthouse maintainer turned it down in issue 10532:

The team's goal here is to increase the visibility of the fact that the score will be different depending on test location, not to eliminate its influence.

The thread didn't settle there. Another maintainer replied that consistent results for any user location are the better goal, and that the variance is the bug to fix. Six years on there's still no picker, and PSI now shows which location it used. The same thread pointed people at paid services for guaranteed test locations, which is the whole reason this category of tool exists.

If you drive PSI from a script rather than the web page, its quota is the next wall. PageSpeed Insights API rate limits covers the error you get and what the payload tells you.

How do you test from several regions?

Pick one region near your origin and one far from it. Then compare the right numbers, which are not the scores.

1. Open both report files. Read the network-rtt audit first.
2. Compare the per-origin values, not the page total. A large gap between two origins is the thing simulation preserves.
3. Check whether the same IP answered. A different one means you measured a different server.
4. Read Time to First Byte outside Lighthouse. It's unthrottled, so it shows the real distance that simulation removed.

Our own free one-URL tool runs up to two regions per request and returns a result for each. Every result carries an unthrottled connection breakdown beside the Lighthouse numbers: DNS, TCP, TLS and TTFB. The list of regions is on the homepage. The /api/v1 audits endpoint takes the same region list and returns one result per region.

What this won't tell you

These are single runs, one per region, not medians. We publish what a single Lighthouse run is worth separately, and it isn't much on a busy page.

It's also still lab data. A region tells you what a machine in Sydney measured on a modelled 150 ms connection. It doesn't tell you what a phone in Sydney experienced on the network it actually has. For that you want field data, and no synthetic tool of ours or anyone else's is a substitute.

We'd rather say that than imply our region list measures something it doesn't. Region testing catches a slow second origin, a bad edge, and a server that answers differently by geography. Those are real and common. The distance itself, under Lighthouse's defaults, mostly isn't in the number.