Methodology
Speedbug runs the whole test from your browser against a dedicated measurement server, 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 with 2 streams and widens while the rate is still climbing, 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, the looser bound covering 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 a short quiet pass against our fixed reference server — that sets the baseline bufferbloat is judged against. Then a run of 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.
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 verdict grades whichever direction is worse, against quiet baselines taken before and after the transfers, so drift on the path to the reference is never charged to your connection. The extra delay that appears under load is bufferbloat — the reason calls and games stutter during a big transfer even on a fast connection. Your latency while downloading and while uploading is shown as a full figure, idle plus what the load added, the shape other tests print.
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. Speedbug's own reference server in Chicago, US still works behind the scenes for the parts that don't depend on distance — the bufferbloat baseline and the hop-by-hop path trace. What Speedbug adds on top of a speed number is exactly those parts: 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.