Verdict first, evaluated January 2026: ping is the weakest of the three metrics and should never appear in a delivery SLA. Ping reports ICMP round-trip time to a network interface. Latency, in delivery terms, means time to first byte over a real TLS connection, and it typically lands 3–4x higher than ping on the identical path. Throughput predicts almost nothing for small objects and almost everything for video segments and software downloads. Any network latency measurement program that stops at ping is instrumenting the wrong layer, and every CDN bake-off built on it produces a defensible-looking answer to the wrong question.
Ping is the round-trip time of an ICMP echo request and reply between your host and a network interface on the far end. It touches no application, no TLS stack, no cache lookup, and on most edge routers it is handled by a deprioritized control-plane path with its own rate limiter.
Latency, for anyone shipping bytes to users, is the interval between a user action and the first useful byte arriving. Operationally that is time to first byte (TTFB), decomposed into DNS resolution, TCP or QUIC connect, TLS handshake, edge cache lookup, and origin fetch on a miss.
Throughput is the sustained rate of application-layer bytes delivered once a connection is warm, measured as goodput rather than link capacity. It is a function of congestion window growth, loss, receive buffers, and round-trip time, which is exactly why it is not independent of latency.
Ping measures ICMP round-trip time to a network interface, while delivery latency measures time to first byte over an established TLS 1.3 connection. On a path with a 40 ms ping, a cold HTTPS request spends roughly three round trips before the first byte arrives, putting realistic TTFB at 120–160 ms in 2026 measurements. That 3–4x gap is why ping is a poor proxy for user-perceived latency and why it belongs nowhere near an availability or performance contract.
| Metric | What it actually measures | What it predicts | Where it lies to you |
|---|---|---|---|
| ICMP ping RTT | Control-plane round trip to an interface | Rough geographic proximity, gross routing breakage | Rate-limited or dropped; anycast makes the responder ambiguous; ignores server work entirely |
| TCP connect time | One data-plane round trip plus SYN backlog handling | True path RTT as the transport sees it | Hidden by connection reuse; invisible on QUIC with 0-RTT resumption |
| TLS handshake time | One extra RTT under TLS 1.3, two under TLS 1.2 | Cost of cold connections for new visitors | Session tickets hide it in synthetic reruns, not for first-time users |
| TTFB (cache hit) | Path RTT plus edge lookup and response assembly | API responsiveness, manifest fetch, Largest Contentful Paint start | Averages hide the p95 tail where cache misses live |
| Goodput | Application bytes per second on a warm connection | Video bitrate ladder headroom, patch download time | Single-stream tests understate parallel-fetch reality; short tests measure slow start, not steady state |
The single conclusion: TTFB at p95 and goodput on a warm connection are the only two rows in that table worth putting in a contract, and ping is not one of them.
Latency predicts experience for anything under roughly 100 KB, and throughput predicts it for anything above roughly 1 MB. Between those points both matter, because transfer time is dominated by how many round trips congestion control needs before the window is large enough to fill the path. Object size decides which metric you should be optimizing.
Two edges advertise 1 Gbps. Edge A sits 20 ms away, Edge B 100 ms away. Ship a 1 MB object from each, cold connection, standard TCP slow start with an initial congestion window of 10 segments and a 1460-byte maximum segment size.
One megabyte is about 718 segments. Slow start delivers a cumulative 10 times (2 to the power n, minus 1) segments after n round trips, so you need 7 round trips to clear 718 segments, plus roughly 3 for DNS, TCP, and TLS 1.3 setup. Edge A: 10 round trips at 20 ms equals about 200 ms, an effective 42 Mbit/s. Edge B: 10 round trips at 100 ms equals about 1,000 ms, an effective 8.4 Mbit/s. Same link capacity, five times the delivery time.
Now the receive-buffer trap. Bandwidth-delay product on a 100 Mbit/s, 100 ms path is 1.25 MB in flight. A client or middlebox stuck with an unscaled 64 KB window (no window scaling per RFC 7323) caps that connection at roughly 5.2 Mbit/s regardless of how much capacity either side has. Engineers chasing this symptom often blame the CDN, then discover it in a packet capture on their own load balancer.
Measure at the layer your users experience, not the layer that is easiest to poll. That means an HTTP client that reports the DNS, connect, TLS, first-byte, and total phases separately; real user monitoring built on W3C Resource Timing and Navigation Timing; and percentile reporting at p50, p95, and p99 with the sample count published alongside. Averages across regions are decorative.
| Approach | Effort | Question it answers | Honest limitation |
|---|---|---|---|
| ICMP probing | Minutes | Is the path up and roughly how far is it | No application signal; frequently deprioritized in hardware |
| Synthetic HTTP from cloud regions | Hours | Phase-level TTFB, cache hit behaviour, header correctness | Cloud regions sit on premium transit; results flatter every vendor by 20–50 ms versus real last-mile users (estimate) |
| Real user monitoring | Days | What your actual users on actual networks get | Sample bias toward engaged users; cross-origin timings need Timing-Allow-Origin |
| Sustained throughput test | Hours | Goodput ceiling for large objects and video segments | Tests shorter than 10 seconds mostly measure slow start, not steady state |
| Packet capture on the client | Days | Retransmits, window limits, congestion control behaviour | Does not scale to fleet-wide monitoring; QUIC payloads are encrypted |
The single conclusion: run synthetic HTTP for controlled vendor comparison and real user monitoring for truth, and treat any disagreement between them as a finding rather than an error.
Most CDN performance testing fails on cache state, not on the network. If vendor A serves your test object from a warm cache and vendor B fetches it from origin, you have measured your own test harness. Randomize a cache-busting path suffix for miss testing, then run a separate warm pass, and report the two populations separately.
Four rules that survive contact with procurement. Use identical object sizes across vendors, at minimum 10 KB, 100 KB, and 5 MB. Test from residential or mobile vantage points, not only cloud regions. Run for at least seven days to catch peak-hour congestion and route changes. Compare p95, and publish the sample count next to every figure.
Trade-off worth stating plainly: a vendor that wins on p50 TTFB by 8 ms and loses on p99 by 400 ms is the worse choice for most workloads, because tail latency is what users report and what breaks adaptive bitrate ladders. Cold-cache TTFB is where storage architecture shows up, and it is invisible to ping: BlazingCDN, for instance, runs NVMe SSD storage at the edge, which affects miss-path first-byte time rather than round-trip time. Compare that class of CDN edge features that shape time to first byte on your own object mix before reading anyone's marketing chart.
No. Ping is ICMP round-trip time to a network interface; latency in delivery terms is time to first byte for an HTTP response, which includes DNS, transport and TLS handshakes, and server processing. A 40 ms ping commonly corresponds to 120–160 ms TTFB on a cold connection, because TLS 1.3 setup alone costs two additional round trips before the request is even sent.
For a cache hit served near the user, 20–60 ms TTFB at p50 and under 150 ms at p95 is a reasonable 2026 target for static assets. Cache misses that traverse an origin shield typically add 40–200 ms depending on origin distance and processing. Judge vendors on the miss path, since hits are easy for everyone.
Use an object of at least 50 MB, run the transfer for a minimum of 10 seconds, and discard the first 2 seconds so slow start does not dominate the average. Run parallel connections to mirror how browsers and video players fetch, then report both single-stream and aggregate goodput at p50 and p95 across your real client geographies.
Use both, for different questions. Synthetic monitoring gives controlled, repeatable comparison between vendors with identical objects and cache states. Real user monitoring, built on W3C Resource Timing, tells you what last-mile users on congested mobile networks actually receive. Synthetic results from cloud regions typically look 20–50 ms better than real user data, an estimated gap worth quantifying for your own audience.
Because congestion control fills the pipe in units of round trips. Slow start doubles the congestion window each RTT, so a 100 ms path needs five times longer than a 20 ms path to reach the same window. Bandwidth-delay product sets the ceiling: at 100 ms RTT, a 64 KB receive window caps a connection near 5.2 Mbit/s.
Pick three object sizes (10 KB, 100 KB, 5 MB), two cache states (forced miss with a randomized path, then warm), and three vantage classes (cloud region, residential broadband, mobile). Record DNS, connect, TLS, and first-byte phases separately, run for seven days, and report p50, p95, and p99 with sample counts. Then compute what a 100 ms p95 improvement is worth against your own conversion or rebuffer data before you negotiate anything. If your current dashboard shows a single average ping number, delete that panel first — it has been shaping decisions it was never qualified to make.