Methodology
Speedbug runs the whole test from your browser, then turns the raw numbers into a plain-language read on your connection. Here is what each part measures.
Download & upload
Parallel streams saturate the link, measured against the nearest Cloudflare edge — the closest point on the internet — so the figure is your real speed, comparable to fast.com and Ookla. The test is adaptive: it starts 2 streams wide — up to 4 on high-latency paths, which need more in flight to fill — and adds one a second only while the rate is still climbing, to a ceiling of 6 on download and 4 on upload, so a link that 2 streams already fill stays at 2. Transfer sizes grow as the link proves fast, and after a 5-second minimum, the moment the reading holds steady for 2 seconds it stops — no data is spent confirming a number that is already settled. Steady means within 3% on download and 5% on upload, judged with the extremes set aside (the 2 highest and 2 lowest readings) — a stray spike or a slow drift in the link shouldn’t buy more of your data, and a genuinely unstable link still never passes. The looser upload bound covers the spikes each request start puts into the upload signal. A time cap and an absolute data cap bound links that never settle — and the result names how each phase ended, because the ending decides what the number is. A settled phase reports its converged window’s average. One that hit the time limit reports the median of its steadier second half, with the ramp-up excluded. One that hit the data cap reports the average of its final samples. Upload is counted from bytes the server acknowledged, not bytes buffered on the way out, so a congested uplink cannot over-report.
Latency & jitter
The run opens with tiny round-trips to your nearest server — the same point fast.com and Ookla measure, so the numbers are comparable and distance never counts against you. The median is your ping, and jitter is how much that ping wobbles. Each probe subtracts the processing time the server itself reports spending on the request, so the figure is the network’s, not the server’s. This idle pass is also the quiet reference bufferbloat is judged against.
Bufferbloat
We measure latency again while the download is saturating the link, and once more while the upload is — the two directions queue in different buffers, and your voice on a call goes out through the upload one. The loaded probes go to the same nearest server as the idle pass, corrected the same way, so your latency while downloading and while uploading is a direct measurement — and the extra delay above your idle ping is bufferbloat, the reason calls and games stutter during a big transfer even on a fast connection. The verdict grades whichever direction is worse, over the saturated stretch of each transfer — probes taken after the rate first reached 90% of the phase's reported figure, the way the IETF responsiveness method measures once working conditions are reached — so the ramp-up never dilutes the reading. The graded figure is the average added delay across that stretch — the statistic the other letter-graded bufferbloat test uses, on the same scale, so one connection reads grade for grade across tools — and the downloaded report prints the typical (median) and worst-5% figures beside it, so a spiky queue can't hide behind a central number. A run where too few loaded probes answer says so rather than showing a number. One thing worth knowing if you compare tools: how much delay a link builds depends on how hard it is being pushed, so an added-delay figure only means something next to the load that produced it. Both Speedbug apps apply the same load — the adaptive widening described above — so one connection gets one number whichever you run. A tool that pushes harder can honestly report a bigger figure for the same line. A deeper queue is still a real queue.
Path trace
We trace the route from the server back toward you, one hop (router) at a time, and show where round-trip time jumps — inside your own network, your ISP, or out on the wider internet.
How the numbers line up with fast.com and Ookla
Latency depends on which serveryou measure against, so Speedbug measures everything the way those tools do: latency, jitter, download, and upload all run against your nearest server — the closest point on the internet. A link that reads 5 ms to a CDN a city away and 70 ms to a server 2 time zones over is the same link, so distance never counts against you. Every latency figure — idle and under load — is measured to that nearest server. Speedbug's own server in Chicago, US still works behind the scenes for one thing that can't run from your browser: the hop-by-hop path trace, which runs from a fixed point back toward you. What Speedbug adds on top of a speed number: how much latency rises under load, packet loss, jitter, and which hop on the path the trouble starts at.
Anonymous by default — a test stores nothing unless you are signed in. Speeds are in Mbps (megabits per second), the standard for internet plans. 8 megabits = 1 megabyte.