How Connection Vitals measures responsiveness
The important numbers should be auditable. This page documents the measurement engine, grade thresholds, our 0–100 score, interpretation rules and known limitations.
Measurement engine
Connection Vitals V2.2 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 CV-1.2 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.