Free tool

China Website Speed Test

A standard Lighthouse audit, executed from inside mainland China instead of from somewhere that can still reach your origin.

By the 21YunBox China Engineering Team · Reviewed 2026-08-27 · Lighthouse CLI, probes in mainland China

Short answer Google PageSpeed Insights cannot measure China — it audits from Google infrastructure, which does not reach the mainland, so its score describes a network path no Chinese visitor takes. This tool runs the same Lighthouse audit from probe nodes inside China. And the fastest path available is also the one that requires an ICP filing, because removing the cross-border round trip means serving from inside the mainland.

Not loading? Open the China Website Speed Test directly.

A run takes roughly 23 seconds. Sites hosted outside China take longer — that delay is the measurement, not a fault in the tool.

Two different problems produce the same bad score

Reading a China Lighthouse result usefully means separating them, because only one of them can be fixed by moving delivery closer.

Cause	What it looks like in the report	Does moving delivery closer help?
Distance and congestion	Everything loads, slowly. High TTFB, long tail on every request.	Yes — this is what shorter paths are for.
Unreachable dependencies	Page shell arrives, then stalls. Individual hosts never respond at all.	No. A CDN makes a reachable host closer. It cannot make an unreachable host answer.

The three delivery paths

Speed and filing are not two separate questions. They are the same question asked twice:

Path	Where the request ends	Cross-border round trip	ICP filing
Offshore origin	Outside China	Full	Not required
Nearshore edge (HK / SG)	Outside the mainland	Shortened, not removed	Not required — it never enters China
In-China delivery	Inside the mainland	Removed	Required

Read the middle row and the bottom row together. The nearshore option is exempt from filing for precisely the reason it cannot close the gap: it stays outside. The path that removes the round trip is the path that enters the mainland, and entering the mainland is the event that triggers the filing — which needs a mainland legal entity and is bound to the access provider, not only the domain. That is the whole decision, laid out in one reference page.

What we measured with this, from inside China

We ran the same reference page through four delivery arrangements and measured each from a probe in Shanghai, five interleaved rounds, on 2026-08-28. The result is not a latency ranking — it is a completion result.

Delivery arrangement	Time to first byte	Finished loading within 60s	Embedded video & form verification
Offshore origin	140ms	0 / 5	0 / 5
Nearshore edge (Hong Kong)	35ms	0 / 5	0 / 5
Inside mainland China, ICP filed	33ms	0 / 5	0 / 5
Inside mainland China, via the 21YunBox Optimizer	493ms	5 / 5	5 / 5

Note the third row. It is served from inside mainland China under a live ICP filing, it posted the best time to first byte of all four, and it failed exactly as completely as serving the page from the other side of the Pacific — the video never played and the form could never be submitted, on every attempt. The fastest first byte belonged to a path that never finished loading.

Probe on a different network from every measurement target, so no path had a home-network advantage. First-party assets byte-identical across the first three arrangements, verified by checksum before each run. The probe is a datacenter line, which has better international transit than a corporate connection — these figures are a floor, not a worst case. Full method and limits →

Frequently Asked Questions

Why does Google PageSpeed Insights not reflect what users in China see?

PageSpeed Insights runs its audit from Google infrastructure, which cannot reach mainland China. Whatever number it returns describes a network path that no visitor in China takes. To measure the experience inside the mainland the audit has to be executed from inside the mainland — that is what this tool does.

How is this different from a normal Lighthouse run?

The audit itself is standard Lighthouse. The difference is where it runs: probe nodes inside mainland China, behind the same filtering and congestion your visitors are behind. Same metric definitions, different vantage point.

My global scores are good. Why is the China score so much worse?

Two causes, and they need different fixes. The first is distance and congestion: every request to an offshore origin crosses a border that adds latency and drops packets. The second is dependencies that never resolve at all — fonts, tag managers, analytics, video and map APIs on unreachable hosts. The first can be reduced by moving delivery closer. The second cannot: a blocked host is not a slow host, and no amount of caching makes it answer.

Will a Hong Kong or Singapore node fix this?

Partly, and it is worth being precise about why. A nearshore node moves the endpoint of the cross-border trip closer to the user, so the trip gets shorter. It does not remove the trip, because the node is still outside the mainland. That is also the reason a nearshore arrangement needs no ICP filing — it never enters China. The same fact explains both its legal simplicity and its performance ceiling.

Does a faster site need an ICP filing?

The fastest available path does. Removing the cross-border round trip means serving from inside mainland China, and serving from inside mainland China is what triggers the filing requirement — which needs a mainland legal entity and is bound to the access provider, not only to the domain. Any arrangement that avoids the filing has, by construction, kept the border crossing.