How Connection Vitals measures and diagnoses connections
The important outputs should be auditable. This page documents the measurement engines, verdict types, grade thresholds, decision rules and known limitations.
Measurement engine
Connection Vitals V3 uses the open-source @cloudflare/speedtest JavaScript measurement engine, pinned to version 1.12.1. The library uses browser PerformanceResourceTiming and Cloudflare edge endpoints to measure latency and throughput. We disable the library's dedicated measurement/results logging options in our configuration.
Test sequence
- Idle baseline: 24 latency probes establish the quiet baseline.
- Download load: adaptive file sizes ramp from 100 KB through larger sets only when needed. Loaded-latency probes run at the same time.
- Upload load: the same principle is applied in the upload direction.
- Diagnosis: median loaded latency is compared with the idle median; p95 and jitter remain visible as supporting evidence.
The adaptive profile is intentional. A tiny fixed file can finish too quickly on a gigabit connection to create sustained load. Larger steps are skipped when prior steps already last long enough, and slow requests have a safety timeout.
Bufferbloat grade
The grade uses the worse of download-added and upload-added latency. We use the common Waveform/DSLReports-style rubric so the letter grade is easier to compare with an established reference:
| Grade | Worst added latency | Plain-language reading |
|---|---|---|
| A+ | < 5 ms | Exceptional control under load |
| A | 5–29 ms | Very good |
| B | 30–59 ms | Good |
| C | 60–199 ms | Noticeable added delay |
| D | 200–399 ms | Poor responsiveness under load |
| F | 400+ ms | Severe added delay |
Connection Vitals Responsiveness Score
The 0–100 number is our own usability score, not an IETF standard and not a Waveform score. It weights three components:
- 60% loaded-latency control: worse of download and upload added latency.
- 25% idle responsiveness: lower idle latency scores better.
- 15% idle stability: lower jitter scores better.
The score uses continuous interpolation rather than hard grade jumps, so a 59 ms and a 60 ms result remain close even though the displayed letter changes from B to C.
Run quality, not “confidence”
Run quality summarizes whether enough latency samples were captured, whether the tab was hidden, and whether the idle baseline was unusually spread out. It is not a statistical confidence interval and does not claim that one run perfectly represents your network.
Application impact
Gaming, call, streaming and browsing labels are practical heuristics based on measured throughput, p95 loaded latency and jitter. They are deliberately presented as “should feel like” estimates rather than guarantees. A specific game or calling service can behave differently.
Known limitations
- The current load requests use Cloudflare's public measurement endpoints. Results describe the path from your browser to that measurement infrastructure, not every destination on the Internet.
- Browser timing, CPU scheduling, Wi‑Fi state, VPNs, extensions and other traffic can affect a run.
- Throughput is useful context but is not intended to replace a dedicated capacity benchmark.
- Packet loss is not included in the current bufferbloat methodology. We will not infer packet loss from failed HTTP requests.
- ISP/ASN text comes from Cloudflare request metadata and is context, not a claim that the ISP caused the measured problem.
Reference implementations
We recommend comparing important decisions against more than one tool. Useful references include Waveform's Bufferbloat Test and the testing resources listed by Bufferbloat.net.
Remote-access diagnostic methodology
V3 separates measured evidence from guidance. For direct TCP paths, a Cloudflare Worker attempts one connection back to the public IPv4 address that initiated the request on the selected port. A successful connection is reported as verified reachable. A failure is reported only as not reachable; it is not mislabeled as closed or filtered without packet-level evidence.
CGNAT and double-NAT verdicts are based on router WAN IPv4 compared with the detected public IPv4. A WAN address in 100.64.0.0/10 is strong carrier-grade NAT evidence. RFC1918 private WAN addresses indicate an upstream private NAT layer. Relay and overlay products such as Tailscale or vendor relay services switch to guidance mode because no public inbound port may be expected.
For selected HTTP services, a successful TCP socket can be followed by a lightweight application-layer request. The tool distinguishes socket reachability from application identification.