www.google.com/recaptcha did not respond once in 72 consecutive attempts, at every hour sampled. And a public JS CDN, reachable 100% of the time by both routes, ran a p95 of 1,757ms against a median of 660ms direct, versus 114ms and 103ms delivered — the instability, not the average, is what breaks pages. Most published figures about third-party resources in China are single samples. We have argued before that a single sample is not a measurement — cross-border behaviour there varies by more than two orders of magnitude across a day, and a number taken at 2pm tells you very little about 9pm.
So we ran it properly: five third-party resource categories, sampled every ten minutes, from a probe inside mainland China, each one requested twice — once directly, once through our own delivery network. 720 measurements over twelve hours, covering the evening peak that operators plan around.
To get a comparison at all, this test pushed every resource down both routes. That is not how a site is actually delivered — the route is decided per resource, and two of these five should be left exactly where they are. Publishing which two is the whole point.
What was measured
| Resource | Category | Why it is on the list |
|---|---|---|
fonts.googleapis.com | Web font stylesheet | On a large share of enterprise pages |
fonts.gstatic.com | Web font file | The actual font bytes |
cdn.jsdelivr.net | Public JS CDN | Common script host |
www.googletagmanager.com | Tag manager | Analytics and marketing tags |
www.google.com/recaptcha | Form verification | Gates whether a form can be submitted |
The list is not arbitrary. It comes from measuring real vendor websites from inside China and recording which third-party hosts actually stopped responding — these five categories are what showed up.
Method: probe inside mainland China; each resource requested directly and through our network in the same round; throughput calculated over the body transfer only, excluding time-to-first-byte, so that small files are not dominated by connection setup; 30-second timeout; timeouts counted as results rather than discarded. Times below are China local time.
Results across twelve hours
| Resource | Route | Success | TTFB median | TTFB p95 | Throughput median |
|---|---|---|---|---|---|
| Font stylesheet | direct | 100% | 111ms | 137ms | 2.4 MB/s |
| our network | 100% | 278ms | 303ms | 5.0 MB/s | |
| Font file | direct | 100% | 102ms | 121ms | 4.9 MB/s |
| our network | 100% | 195ms | 208ms | 0.8 MB/s | |
| Public JS CDN | direct | 100% | 660ms | 1,757ms | 4.0 MB/s |
| our network | 100% | 103ms | 114ms | 16.1 MB/s | |
| Tag manager | direct | 100% | 118ms | 143ms | 13.5 MB/s |
| our network | 100% | 312ms | 327ms | 4.1 MB/s | |
| Form verification | direct | 0% | — | — | — |
| our network | 100% | 169ms | 263ms | 1.5 MB/s |
72 samples per cell.
The two that should be left alone
Google Fonts and the tag manager were faster requested directly. 111ms against 278ms for the stylesheet; 118ms against 312ms for the tag manager. Both were reachable in 100% of attempts on this connection, and putting an already-fast, already-reachable host through an additional hop costs roughly 170 to 200 milliseconds. That is the honest arithmetic and we are not going to dress it up: for a host that is genuinely healthy from your visitors’ network, sending it anywhere else is a latency tax.
This is the argument for measuring, not an argument against delivery. A layer that rewrites every third-party reference by default pays that tax on every host that was already fine — and it cannot know which hosts those are, because it never measured them. The decision has to be made per resource, and it has to be made on data from inside China: is this host healthy from Shanghai at 9pm is not a question you can answer from anywhere else.
Two of these five pass that check. The correct action on them is nothing.
The result that decides whether a form works
www.google.com/recaptcha did not respond once. Zero successful requests out of 72, across every hour sampled, from mid-afternoon through the evening peak and past midnight. Through our network, 72 out of 72.
This is not a latency finding, and it is not a gradient. Form verification is the gate on submission: if the widget never loads, the submit button never becomes active. A page in that state is not slow. It is a form that cannot receive a single lead, and nothing in the page reports an error, because the request is issued and simply never answered.
If your China site has a gated contact form and you have never measured this specific thing, it is the first thing worth checking.
The result that only shows up over time
The public JS CDN was reachable in 100% of attempts by both routes. Reachability told us nothing useful. The distribution did:
| China local time | Direct TTFB (median) | Our network | Ratio |
|---|---|---|---|
| 16:00 | 477ms | 103ms | 4.6× |
| 17:00 | 932ms | 99ms | 9.4× |
| 19:00 | 987ms | 104ms | 9.5× |
| 21:00 | 1,076ms | 102ms | 10.5× |
| 23:00 | 548ms | 103ms | 5.3× |
| 01:00 | 728ms | 110ms | 6.6× |
Direct time-to-first-byte more than doubled between the quietest hour sampled and the 21:00 peak. Across the same twelve hours the delivered route stayed between 99 and 110 milliseconds — a spread of eleven milliseconds.
The single number that captures it is the ratio of the 95th percentile to the median:
| Resource | Direct | Our network |
|---|---|---|
| Public JS CDN | 2.7× | 1.1× |
| Font file | 1.2× | 1.1× |
| Tag manager | 1.2× | 1.0× |
A p95 of 1,757ms against a median of 660ms means one request in twenty takes nearly two seconds — and on a page with a dozen such requests, one of them landing in that tail is enough to hold up rendering. This is why an average is the wrong summary statistic for China, and why a figure sampled once is worth very little.
What this adds up to
Three different failure modes, and only one of them is what people usually mean by “slow in China”:
- Some hosts are simply fine. Two of five, on this connection, at every hour sampled. The right treatment is to leave them untouched; anything else makes them worse.
- Some hosts are reachable but unstable. The median looks tolerable; the tail is where the page actually breaks. You cannot see this without sampling across the day.
- Some hosts never answer at all. No error, no timeout event, no signal — and if that host is your form verification, the business consequence is total rather than degraded.
A delivery layer earns its place on the second and third. On the first it earns its place by staying out of the way — which it can only do if it can tell the three apart, and it can only tell them apart by measuring both routes from inside China.
Limits
- Twelve hours, one probe, one city. The remaining twelve hours of this run are still collecting; we will update rather than re-publish.
- The probe is a datacenter line. International transit from a commercial cloud is materially better than from a corporate broadband connection, so every direct-route figure here is optimistic — a real office would see worse.
- Five resources. Chosen because they are common and because they showed up in earlier failure data, not because they are exhaustive.
- Throughput excludes TTFB, which is the fair way to compare small files but means the throughput column and the TTFB column should be read separately.
- This test pushed every resource down both routes, which is what a comparison requires and is not how a site is delivered. The delivered route here is also a simplified configuration built for measurability, not the production arrangement.
What we are measuring next
The same run to a full 24 hours, then repeated from a Chinese office broadband line rather than a datacenter, which we expect to make the direct-route numbers considerably worse and the comparison correspondingly less flattering to publish. We will publish it anyway.
The method behind these numbers, including the eight ways we got it wrong first. And if you want to see which third-party hosts your own site depends on, our China firewall test reports them per resource from inside the mainland.
