Why Your Speed Test Looks Great but Real Users in China Still Complain

You ran the test. Every probe across mainland China came back under 100 milliseconds, the map was a reassuring sea of green, and the report went to the client with a note saying the problem was solved.

Two days later, the complaints are back. Users say the site is still slow, sometimes doesn’t load at all, and the screenshots they send don’t look anything like your test results.

The test probes may use different networks, run at quieter hours, or measure only part of the page load. Real-user timings help show where those tests miss a problem.

Where speed test probes actually live

Most multi-location China speed test services run their probes in data centers. A probe labeled “Shanghai Telecom” is usually a server in a Shanghai IDC, connected close to China Telecom’s backbone with business-grade connectivity.

Your users aren’t in data centers. They’re on home broadband or mobile networks, in apartments and offices, behind carrier-grade NAT, shared last-mile links, and Wi-Fi. The path from a residential connection to the carrier backbone adds latency, loss, and congestion that a data center probe never sees.

That last mile is often where the worst of the evening congestion happens, and it’s outside your control and outside most speed tests. A probe can tell you the route to the carrier’s backbone is clean; it can’t tell you what happens between that backbone and someone’s living room.

The time of day problem

Most people run speed tests during their own working hours. If you’re in Europe or the US, that can miss the busiest Chinese hours; the exact overlap depends on your time zone and season, when networks are quiet.

Chinese consumer traffic peaks in the evening, roughly 8 p.m. to 11 p.m. local time, when international links on standard backbones are most congested. A route that shows 1% loss at 10 a.m. can show 15% at 9 p.m. A test at the wrong hour doesn’t measure the experience that’s generating complaints.

The fix is simple but easy to forget: schedule tests across a full day, and pay most attention to evening peak in China. Our piece on why packet loss predicts a bad China route covers why loss at peak tells you more than any average.

Testing the wrong carrier

China’s three major carriers run separate networks, and routing quality differs a lot between them. A server with excellent routing to China Telecom can have mediocre routing to China Mobile, and vice versa.

If your test focuses on China Telecom probes, or a dashboard averages all three into one number, a poor route to one carrier disappears. China Mobile has the largest subscriber base of the three, especially on mobile, so a weak China Mobile path can affect a big share of your users while the averaged test looks fine.

Always break results out by carrier. Our article on why carrier routing matters more than location explains why one server can behave like three different servers depending on who’s connecting.

Ping isn’t page load

Many quick tests report ping. Ping uses ICMP, which routers and filtering equipment often handle differently from real web traffic, so a clean ping doesn’t guarantee clean TCP. It also only measures one round trip, not the dozens a real page load needs.

Throughput tests have their own blind spot. Many speed tests use multiple parallel connections, which can fill a link even when individual connections are struggling with loss. A browser loading your site opens a handful of connections, and each one feels the loss directly.

What users experience is the full page: DNS lookup, TCP and TLS handshakes, the HTML, then every image, script, stylesheet, and font. A test that fetches only the HTML, or only pings the server, measures a small slice of that.

Third-party resources that don’t load from China

This is often the biggest single cause of the gap. Your speed test checks your server, but your pages load resources from other servers too, and some of them are blocked or extremely slow from mainland China.

Google Fonts, Google Analytics, Google Tag Manager, reCAPTCHA, YouTube embeds, Facebook and X pixels, and many CDN-hosted libraries fall into this category. When a browser can’t reach one of them, it doesn’t fail instantly. It waits for a connection timeout, and if that resource blocks rendering, such as a font or a script in the page head, the whole page waits with it.

The result is a server that responds in 80 milliseconds and a page that takes 20 seconds to become usable. No server-side test will show that. Audit every external domain your pages load, and self-host or replace anything that doesn’t load reliably from China.

DNS and caching differences

Your test probe may resolve your domain differently from your users. Many Chinese users rely on their carrier’s DNS resolvers, and if you use GeoDNS or a CDN, different resolvers can get different answers. DNS responses for some foreign domains can also be tampered with or slow inside China.

Caching skews results too. Repeated tests hit warm caches at the CDN, at the server, and sometimes in the test tool itself. A first-time visitor on a slow connection downloads everything cold.

How to measure what real users see

The answer is real user monitoring, or RUM: collecting timing data from actual visitors’ browsers. Every modern browser exposes detailed timings through the Navigation Timing and Resource Timing APIs, including DNS, connection, TLS, time to first byte, and load milestones. Reused connections can show zero connection timings; cross-origin resource details require appropriate Timing-Allow-Origin headers. A load-event beacon also misses visitors whose page never loads or who leave early.

Because many common analytics tools load poorly from China, the most reliable approach is a small self-hosted beacon that sends timing data to your own server. Here’s a minimal version:

window.addEventListener('load', () => {
  setTimeout(() => {
    const t = performance.getEntriesByType('navigation')[0];
    if (!t) return;
    navigator.sendBeacon('/rum', JSON.stringify({
      dns: t.domainLookupEnd - t.domainLookupStart,
      tcp: (t.secureConnectionStart > 0 ? t.secureConnectionStart : t.connectEnd) - t.connectStart,
      tls: t.secureConnectionStart > 0 ? t.connectEnd - t.secureConnectionStart : 0,
      ttfb: t.responseStart - t.requestStart,
      load: t.loadEventStart,
      page: location.pathname
    }));
  }, 0);
});

On the server, validate and rate-limit the beacon endpoint. If you use IPs to infer carrier, minimize retention and avoid logging sensitive URL paths; performance monitoring still needs an appropriate privacy basis and notice. Derive the carrier and discard or truncate the raw address where practical. Mapping IPs to their autonomous system tells you which carrier each visitor is on, so you can split results into China Telecom, China Unicom, and China Mobile. Record the hour too.

Look at percentiles, not averages. The median tells you what a typical visit feels like; the 90th and 95th percentiles tell you what your unhappiest users are experiencing, and that’s usually where complaints come from.

Make synthetic tests more realistic

Synthetic tests are still useful, as long as you design them to match reality. Test at evening peak in China, not just your own working hours. Break results down by carrier and by region, including inland provinces, not just Beijing, Shanghai, and Guangzhou.

Test full page loads, not just pings or single requests. Some China-based testing services, such as ITDOG and 17CE, offer full-page or multi-step tests from many carrier and province combinations, which gets closer to real experience than a ping map.

When possible, add a real device. A phone on a Chinese mobile network, or a colleague or partner willing to share screenshots and timings, is often more revealing than another round of data center probes.

Closing the gap

Once you know where the gap comes from, the fixes are usually clear. If third-party resources are the problem, self-host fonts and scripts and remove anything blocked. If one carrier is weak, look for a server with premium routing on that carrier, such as CMIN2 for China Mobile. If evening loss is the problem, the route itself is likely using a congested standard backbone.

Server location and routing set the floor. A China-optimized route on all three carriers can reduce international congestion, but still needs testing at peak, and everything else, from handshake tuning to asset trimming, builds on top of that.

Wrapping up

A great China speed test and unhappy users can both be true at the same time. Probes sit in data centers, tests run at quiet hours, carriers get averaged together, ping isn’t page load, and blocked third-party resources hide behind a fast server response.

Measure real users with a self-hosted beacon, split results by carrier and hour, look at percentiles, and make synthetic tests match how your visitors actually connect. That’s how you find out what’s really slow.

Thanks for reading! If your measurements point to the route itself, V.PS runs KVM VPS on its own networks in 11 cities across 3 continents, and the Performance KVM VPS in Tokyo and Singapore carries CTGNet, CUP, and CMIN2 routing to all three major Chinese carriers. Every location has a public looking glass so you can test before you buy.

Ready to get started? Deploy a server or contact our team if you need help choosing a plan.

Frequently asked questions about China speed tests and real user performance

Why does my website pass China speed tests but still load slowly for users?

Speed test probes usually run in data centers, at times that may not match Chinese peak hours, and often only measure ping or a single request. Real users face last-mile congestion, evening peaks, carrier-specific routing, and third-party resources that may be blocked in China.

What time should I test website speed from China?

Test across a full day, with extra attention to evening peak in China, roughly 8 p.m. to 11 p.m. local time. That’s when standard international routes are most congested.

Why do Google Fonts and analytics slow down my site in China?

Many Google services are blocked or unreliable from mainland China. A browser waits for those requests to time out, and if they block rendering, the whole page waits. Self-hosting fonts and scripts removes the problem.

What is real user monitoring?

Real user monitoring collects performance data from actual visitors’ browsers using APIs like Navigation Timing. It shows what users experience on their own networks, rather than what a test server sees.

Should I test China Telecom, China Unicom, and China Mobile separately?

Yes. The three carriers run separate networks with different routing quality, and averaging them together can hide a poor route to one carrier that affects many of your users.

Is ping a good measure of website speed from China?

Not on its own. Ping uses ICMP, which can be handled differently from web traffic, and measures a single round trip. A page load involves many round trips and resources, so full page timing is more useful.