CONCEPT Cited by 1 source
Connection time¶
Connection time is the wall-clock time for an end-user device to complete the handshake with the endpoint it's trying to reach — typically DNS + TCP handshake + TLS handshake (and, on HTTP/3 connections, QUIC + TLS 1.3 fused handshake). It's the latency metric Cloudflare uses as the headline measure in its periodic network-performance posts because it "most closely approximates what users actually perceive as 'Internet speed'" (Source: sources/2026-04-17-cloudflare-agents-week-network-performance-update).
Why this metric, not others¶
Cloudflare's stated framing against alternatives:
- vs. throughput / bandwidth — throughput is dominated by the size of the transfer, the TCP/QUIC window ramp-up, and link-layer capacity. It rewards "how fat is the pipe" but ignores the pre-transfer setup cost that dominates small- request loads (API calls, tracking pixels, most web page sub-resources).
- vs. total page-load time / largest-contentful-paint — too noisy; confounds CDN performance with origin compute, page weight, client render, and user behaviour.
- vs. TTFB (time-to-first-byte) — includes the origin's server processing time, which a CDN-provider benchmark should not include.
- vs. ping / ICMP RTT — single packet, no handshake; ignores TLS termination cost (a large share of edge CPU) and is often deprioritized / rate-limited differently from TCP along the path.
Connection time is precise enough to be actionable (captures the pre-transfer handshake cost that a CDN can directly attack) but situated enough to match user perception (includes congestion, geographic distance, and the realities of the handshake hot path).
What improves connection time¶
The post separates improvements onto two orthogonal axes (the toll-booth analogy):
- Shorter distance / more booths — denser PoP footprint. Cited instances: Wroclaw Poland (free-tier RTT 19 → 12 ms, −40 %), Malang Indonesia (Enterprise RTT 39 → 37 ms, −5 %). Reduces the physical round-trip-time floor for users nearest the new PoP.
- Faster booths — software efficiency in the connection-handling hot path: protocol upgrades (HTTP/3 fuses TLS into the transport handshake, saves a round-trip), congestion-window tuning (start bigger → initial data in flight sooner → measured handshake-plus-first-byte time shorter), CPU / memory wins in SSL/TLS termination, traffic management, and core proxy code.
Aggregation choice matters¶
Raw per-connection measurements are noisy. Cloudflare uses the trimean of per-network connection-time samples:
"The trimean is a weighted average of three values: the first quartile (25th percentile), the median (50th percentile), and the third quartile (75th percentile). This approach smooths out noise and outliers, giving us a cleaner signal about the typical user experience rather than an extreme case that might skew the picture."
This intentionally discounts tails. For provider ranking on typical-user experience, trimean is cleaner than mean (too skewed by outliers) and cleaner than a single percentile (too noisy). For worst-case user experience, the wiki's tail-latency framing is the right lens, and connection time aggregated with trimean will not surface tail problems that matter at fleet scale.
Measurement: how the samples are produced¶
Samples come from Real User Measurement — a browser-side speed test that fetches small files from multiple CDNs in parallel and times each exchange. The RUM cohort is users who loaded a Cloudflare error page (non-trivial sampling bias on the cohort, but no synthetic-test track bias).
Trade-offs / caveats¶
- Hides tail performance. Trimean on connection time rewards a provider with competitive Q1 / median / Q3 even if p99 handshake time is much worse. For AJAX-heavy apps where every user makes dozens of handshakes, the 99th- percentile connection is the user-visible one.
- Handshake-only — doesn't measure steady-state throughput. A provider can win connection time and lose on large downloads. For mixed workloads, one number is not enough.
- Platform-dependent definition boundary. Depending on how it's instrumented, connection time may or may not include DNS resolution (which is dominated by the user's resolver, not the CDN). Fair cross-provider comparison requires identical boundaries.
- Methodology bias flows straight through. If the sample population is not representative (error-page cohort, one browser family, one region), the connection-time ranking inherits that bias. See concepts/benchmark-methodology-bias.
Seen in¶
- sources/2026-04-17-cloudflare-agents-week-network-performance-update — canonical wiki instance. Cloudflare uses trimean of connection time against top-5 CDN providers, gathered via RUM from Cloudflare-branded error pages, against an APNIC top-1,000-networks-by-population denominator, and reports the fraction of networks where Cloudflare wins (40 % → 60 % Sept → Dec 2025) plus the average gap to next-fastest (6 ms in Dec 2025).