Measurement methodology
What SpeedPulse measures, how it measures it, and what a single test cannot prove.
Evidence for every result
Measured
Speed, baseline latency, jitter, and loaded latency are observed during the test against the selected server. Packet loss is included only when the engine executes that measurement.
Calculated
The bufferbloat delta and A+–F grade are derived from observed metrics. This is a SpeedPulse scale; RFC 9097 does not standardize it.
Estimated
Regional loaded-latency projections are not pings to game servers. They are cloud references combined with the measured local queue delay.
Cloudflare engine
Uses HTTPS requests to the Cloudflare edge for application performance and latency probes. It describes the path to that edge, not guaranteed last-mile capacity or performance to every destination.
24 baseline probes; loaded probes every 250 ms; up to 100 samples retained. The transfer ladder adapts to the selected duration.
M-Lab NDT7 engine
Uses WebSocket over NDT7 with the assigned M-Lab server. It measures application goodput and transfer RTT to that machine; results depend on the device, Wi‑Fi, ISP, path, and server.
Limits and repetition
One test is a snapshot. Repeat under comparable conditions, preferably on Ethernet with no parallel transfers, and compare the median of several runs before changing equipment or contacting your ISP.
Packet loss is shown only when the engine measured it; when the active protocol does not provide it, SpeedPulse labels it as not measured. It is never replaced with 0%.
References: RFC 9097 · M-Lab NDT7 · Cloudflare AIM