There is a persistent assumption in China web projects that the problem is distance, and that the fix is therefore location: get the bytes closer, ideally inside the mainland, and the site will work. We wanted to know how much of that is true, so we measured it rather than argued about it.
What we measured
One reference page, built to look like an ordinary enterprise page: HTML, stylesheet, script, a 219KB hero image, a web font, a tag manager, a script from a public CDN, an embedded video, a contact form gated by a verification widget, a cross-border API call, and a lead form posting to an endpoint on the origin.
That inventory is not arbitrary. It comes from measuring twelve real vendor websites from inside China the week before and recording which third-party hosts actually stopped responding. The categories that showed up — fonts, tag management, advertising and analytics, media assets, cloud static assets — became the checklist. We did not pick capabilities we knew we could deliver.
The same page was then served four ways:
| Delivery arrangement | ICP filing | Third-party references | |
|---|---|---|---|
| 1 | Offshore origin | Not required | Unchanged |
| 2 | Nearshore edge, Hong Kong | Not required | Unchanged |
| 3 | Inside mainland China | Required | Unchanged |
| 4 | Inside mainland China, via the 21YunBox Optimizer | Required | Rewritten to same-origin paths |
Paths 1 through 3 serve byte-identical content — verified by comparing the SHA-256 of every first-party asset across all three hosts before each run. Path 4 is the same origin content with third-party references rewritten to same-origin paths served from inside China. That rewriting is the treatment being measured, and it is disclosed: no dependency was removed. Path 4 issues more requests than the others, not fewer, because resources that were dead on the other paths actually load.
Probe: Shanghai, on a different cloud provider from every measurement target, so no path gets a home-network advantage. Five interleaved rounds — each path measured once per round, in rotation — so that time-of-day variation shows up as noise across all four rather than as a difference between them.
Results
| TTFB | FCP | LCP | Finished loading within 60s | Requests | |
|---|---|---|---|---|---|
| 1 Offshore origin | 140ms | 2,468ms | 8,176ms | 0 / 5 | 14 |
| 2 Nearshore (Hong Kong) | 35ms | 548ms | 1,480ms | 0 / 5 | 15 |
| 3 In-country, ICP filed | 33ms | 560ms | 920ms | 0 / 5 | 15 |
| 4 In-country, via Optimizer | 493ms | 1,120ms | 1,124ms | 5 / 5 | 34 |
Capability outcomes, five attempts each:
| Web font | Tag manager | Embedded video | Form verification | Cross-border API | |
|---|---|---|---|---|---|
| 1 Offshore | 5/5 | 5/5 | 0/5 | 0/5 | 5/5 |
| 2 Nearshore | 5/5 | 5/5 | 0/5 | 0/5 | 5/5 |
| 3 In-country, filed | 5/5 | 5/5 | 0/5 | 0/5 | 5/5 |
| 4 Via Optimizer | 5/5 | 5/5 | 5/5 | 5/5 | 5/5 |
Third-party hosts that never responded at all: two on paths 1, 2 and 3 — identical on all three. None on path 4.
Three things this shows
The question is not “how fast”, it is “does it finish”
Three of four delivery arrangements failed to complete a page load in 60 seconds, on every attempt. That is not a performance gradient; it is a binary outcome, and it is the one a visitor experiences. A page whose video never plays and whose form can never be submitted is not a slow page. It is a page that does not work.
Row 3 is the most important row, because it is the one that is bad for us
We sell in-country delivery. The in-country, ICP-filed, otherwise-unmodified path in row 3 posted the best time-to-first-byte (33ms) and the best largest-contentful-paint (920ms) of all four arrangements — and its video, its form verification, and its load completion were indistinguishable from serving the page out of a datacenter on the other side of the Pacific.
The site is legal. The site is close. The site still does not work.
This is the clearest evidence we have that an ICP filing and an in-country server are not, by themselves, the answer. They are a precondition for the arrangement that does work, which is a different claim and a much narrower one. We have written separately about why, and this is the measurement behind it.
The fastest first byte belonged to the path that never finished
Row 3 wins TTFB by fifteen times over row 4. Row 4 is the only row that completes. If you optimise for the headline latency number — which is what most China performance conversations optimise for — you will pick the arrangement that fails.
What does not favour us, stated plainly
Path 4 has the worst time-to-first-byte of the four, by an order of magnitude. 493ms against 33ms. The page’s own HTML travels out of the mainland and back before it reaches the browser. We have described this elsewhere as removing the cross-border round trip; that was wrong, and this measurement is what corrected it. The round trip is not removed. It is moved off the browser’s critical path, where it is paid once over a warm pooled connection instead of dozens of times over cold ones.
Path 4’s largest-contentful-paint is slightly worse than path 3’s — 1,124ms against 920ms. Path 3 is serving static files from a local disk with nothing in the way. It should win that number, and it does.
The gap between nearshore and in-country is much smaller than we expected. On static delivery latency, offshore to nearshore is a 5.5× improvement; nearshore to in-country is 13%. A nearshore edge captures most of the raw latency benefit for a page this light. A heavier enterprise site with more round trips would widen that gap, but 13% is what we measured and we are not going to describe it as a multiple.
The lead form succeeded on all four paths, so it did not differentiate anything. Our test endpoint sits on our own origin and is reachable from China, just slowly. Real marketing automation endpoints frequently are not. This capability needs a more representative endpoint before it means anything, and until then we are not using it as evidence.
Limits of this measurement
- The probe is a datacenter line, not an office line. From it, two of the third-party hosts we expected to fail were actually reachable, while others were not. A commercial cloud has materially better international transit than a corporate broadband connection. Every number here is a floor, not a worst case.
- The reference page is light. Fewer first-party assets than a real enterprise site, therefore fewer round trips, therefore a smaller measured gap between paths 2 and 3 than a production site would show.
- Five rounds per path. Enough to establish a binary outcome that was consistent every time; not enough to characterise the distribution of the continuous ones. A 24-hour sampling run addressing that is in progress.
- Path 4’s video handling here is a simplified configuration built for measurability, not the production arrangement.
- One day, one probe location. Cross-border behaviour in China varies by more than two orders of magnitude across a day.
What we are measuring next
A 24-hour run sampling five third-party resource categories every ten minutes, direct against delivered-through-our-network, reported by hour of China local time rather than averaged — because the daily average erases the evening degradation that operators actually plan around. Then the same reference page from a Chinese office broadband line, which will make every figure above look better than reality by comparison.
We will publish those too, including whatever they say.
You can run the same reachability check on your own site with our China firewall test, and a Lighthouse audit from inside the mainland with our China speed test. If you want the eight ways we got this measurement wrong before getting it right, that list is here.
