This happens because synthetic monitoring and CrUX measure fundamentally different things: synthetic tools run from a small number of fixed data-center locations on a controlled network path, while CrUX aggregates real Chrome users hitting your origin from wherever they actually are, over whatever network path their ISP happens to route them through. A TTFB spike that only shows up for users in, say, Southeast Asia or Eastern Europe is very often a real-world network-path problem (ISP peering, missing or under-provisioned CDN edge coverage, suboptimal DNS/anycast routing) that a synthetic probe sitting in us-east or western Europe will never traverse, so it never sees the problem.
Why regional network paths cause CrUX-only TTFB spikes
TTFB is the sum of DNS resolution, connection setup (TCP/TLS handshake), any redirects, and the time until the first byte of the response arrives. Every one of those steps is sensitive to physical network topology. A synthetic monitor typically runs from a handful of cloud regions chosen for coverage and cost, not to replicate every real user’s ISP-to-origin path. If your CDN has a well-provisioned edge node near your synthetic monitor’s location but a sparse or oversubscribed edge (or none at all, falling back to a farther-away node or the origin) for a specific region, users in that region will experience real added latency that the synthetic check structurally cannot reproduce, because it never routes through that path.
CrUX, by contrast, is built from real Chrome user telemetry and explicitly supports a country dimension in both the CrUX API and the BigQuery dataset. This is precisely why CrUX can surface regional degradation that lab tooling misses: it’s not a different measurement of the same thing, it’s a measurement of the actual population your synthetic checks aren’t sampling.
Other real-world factors that produce this exact fingerprint (visible in field data, invisible in lab):
- ISP-level peering issues between the user’s network and your CDN/origin’s network, which vary by region and can be intermittent (time-of-day congestion, route flaps)
- Anycast routing sending some regions to a farther-away or less-provisioned PoP than expected due to BGP path changes
- TLS negotiation overhead that’s proportionally worse over higher-latency, higher-jitter regional paths (more round trips feel worse the farther the round-trip)
- Mobile network variability concentrated in regions with a different device/carrier mix than wherever your synthetic monitor’s simulated network profile assumes
The transport protocol in use compounds this further. A connection negotiated over HTTP/2 on TCP still pays a full TCP handshake plus a separate TLS handshake before any bytes move, and on a high-latency or lossy regional path, packet loss during that handshake forces retransmission timeouts that synthetic monitors on clean data-center links essentially never encounter. HTTP/3 over QUIC collapses transport and TLS negotiation into fewer round trips and handles packet loss per-stream rather than blocking the whole connection, which is precisely why regions with congested or lossy last-mile networks (common on certain mobile carriers) sometimes show a meaningfully different TTFB profile between HTTP/2 and HTTP/3 clients. If your CDN supports HTTP/3, checking whether the affected region’s traffic is actually negotiating it, versus falling back to HTTP/2 or even HTTP/1.1, is worth confirming before assuming the problem is purely about PoP placement.
It’s also worth ruling out a common misdiagnosis: intermittent regional TTFB spikes are sometimes blamed entirely on network path when the real driver is origin-side, such as a cache miss ratio that happens to be worse for that region’s traffic pattern (different content mix, different cache key variance) or a backend dependency (database replica, third-party API call) that’s geographically distant from the origin serving that region. Server-Timing response headers, if your backend emits them, let you separate “time spent in network transport” from “time spent in application/backend processing” for the exact requests CrUX is measuring, which is the cleanest way to confirm the spike is genuinely a network-path issue rather than an origin compute issue that merely correlates with region.
Diagnosing regional TTFB spikes with CrUX, RUM, and Server-Timing
Start by actually segmenting the CrUX data by country using the CrUX API or the BigQuery public dataset (chrome-ux-report) rather than relying on an aggregate origin-level TTFB number, since the aggregate can look acceptable while masking a bad tail in specific regions. Confirm the pattern is real and not a sampling artifact by checking whether the affected regions have sufficient CrUX traffic volume to be statistically meaningful.
Once you’ve confirmed which regions are affected, check your CDN’s actual point-of-presence (PoP) coverage and health for those regions specifically, not just your overall CDN footprint. Many CDN dashboards expose per-PoP latency and error rates; look for PoPs near the affected regions that are absent, degraded, or serving as a fallback to a farther node. If you operate origin infrastructure directly, look at whether your DNS/anycast configuration is actually routing those users optimally, since misconfigured anycast can silently send a region’s traffic the long way around.
Layer in a RUM (real user monitoring) tool with geographic breakdown if you need finer granularity than CrUX provides. CrUX gives you country-level (and in some cases coarser subdivision) data with a 28-day rolling window, which is useful for confirming the problem exists but not always granular enough for root-causing it to a specific network segment. A RUM tool integrated into your own site can log connection timing per request with more geographic and even ISP-level detail, letting you correlate TTFB spikes with specific network paths or times of day.
Where you can, instrument Server-Timing headers on your origin responses so you can distinguish backend processing time from network transport time on the actual requests being served, not just on synthetic reproductions. This matters because a RUM tool alone will tell you TTFB is elevated for a region, but not necessarily whether that’s transport or backend, and treating a backend problem as a network problem (or vice versa) sends the fix to the wrong team. If Server-Timing shows backend processing is consistent across regions while total TTFB varies, that’s strong confirmation the issue is genuinely in the network path, not the origin.
Also check whether the affected traffic is negotiating the transport protocol you expect. If your CDN offers HTTP/3, confirm the affected region’s clients are actually using it rather than falling back to HTTP/2 or HTTP/1.1, since a fallback (caused by network middleboxes blocking UDP, for instance) can itself be the source of added handshake round trips that show up as regional TTFB variance.
Finally, treat this as an infrastructure and CDN-configuration problem, not a code problem: no amount of application-level optimization changes a network path issue between a specific region and your edge. The fix lives in CDN PoP provisioning, peering agreements, or anycast/routing configuration, and diagnosing it correctly (via CrUX’s real geographic field data rather than a synthetic check that structurally can’t see it) is the necessary first step before any of those fixes make sense.
