A browser can't send raw pings, so speed tests time HTTP transfers instead. See how warm-up, payload sizing, streams and medians shape the number you get.
Key Takeaways
- A web page cannot send ICMP pings or open raw sockets, so every browser speed test is built from HTTP or WebSocket transfers timed with a clock.
- Throughput is simply bytes received divided by elapsed time, but only after the connection has ramped up, which is why tests use warm-up transfers and discard the early seconds.
- Test design choices (single vs. parallel streams, payload size, median vs. best run) change the headline number on the very same line.
- "Ping" in a browser is an HTTP round trip, so it includes server processing time, not just the wire.
A browser speed test measures your connection by moving real bytes over HTTP (or WebSocket) and timing them with a high-resolution clock. Download speed is the data received divided by the time it took; latency is the time of a tiny request and response. Everything else in a test's design exists to make that simple division honest. This post covers the mechanism only: what moves, what is timed, what is thrown away, and how one number comes out. For why results differ between runs or tools, see why speed test results vary, and for what bandwidth, latency and jitter mean, see the metrics explained.
What can a browser actually measure?
A web page runs in a sandbox. It cannot send ICMP echo requests (the classic ping), cannot open raw sockets, and cannot see packets. What it can do is call fetch(), XMLHttpRequest or a WebSocket, and read the clock. The standard clock is performance.now(), a monotonic timer that is not affected by system clock changes.
That single constraint explains most of the design:
- Latency is an HTTP round trip. The browser times a small request until the response arrives. That includes the server's processing time and any connection handling, so it will usually read a little higher than an ICMP ping to the same host.
- Throughput is observed from the page's side. The test counts bytes as they arrive (or as the upload completes) and divides by elapsed time. It measures what the page can actually move, which is the number that matters for web use.
Why tests need a warm-up
A new TCP connection does not start at full speed. Congestion control begins with a small window and grows it as acknowledgments return, a phase known as slow start. A test that times one small file mostly measures that ramp-up, and under-reports the link.
RFC 6349, the IETF framework for TCP throughput testing, makes the same point: what you want to know is the steady-state throughput the path can sustain, not the first few round trips. In practice, tests handle this in two ways: they send a throwaway warm-up request whose result is discarded, and they use payloads large enough that the ramp-up is a small fraction of the total time.
It also explains why tiny files are poor bandwidth probes. A 1 KB response finishes long before the window opens, so it tells you about latency, not capacity.
Adaptive payload sizes
A fixed file size is wrong for most people. A 50 MB file takes minutes on a weak mobile link; on fibre, a 1 MB file is finished before the connection has ramped up. The usual fix is to start small and grow the payload until a transfer takes a target duration, often a couple of seconds. Slow links stay short, and fast links get enough data to reach steady state.
One stream or many?
Here designs genuinely differ.
- Multiple parallel streams. Many commercial tests open several TCP connections at once. This fills high bandwidth-delay-product links (fast and far away) that a single flow may not saturate, and it tends to report a higher peak.
- A single stream. M-Lab's NDT, in its current ndt7 form, deliberately uses one connection for a fixed duration. Its protocol specification runs the transfer over a WebSocket. The single connection is the point: it wants to measure what one TCP flow achieves on the path.
Neither is wrong. They answer different questions: "how much can this line carry in total?" versus "what will one connection get?". A single stream can under-read a very fast link; many streams can flatter a path where most real traffic is a single flow.
From samples to one number
A test takes many measurements, then has to reduce them to a headline. The choice matters:
| Aggregation | Effect |
|---|---|
| Mean of all runs | Dragged down by slow ramp-up and one-off hiccups |
| Median | Resists outliers; a stable, conservative figure |
| Best run (or top percentile) | Highest number, closest to peak capacity, least typical |
| Trimmed mean (drop top and bottom) | A compromise between the two |
The same line, with the same raw samples, can show visibly different results depending on which of these a tool picks.
Latency under load
Idle latency and latency while the link is busy are different measurements. A line that pings 15 ms when quiet can jump to hundreds of milliseconds once a transfer fills its buffers. The IETF IPPM working group's responsiveness draft formalises measuring this, expressed as round trips per minute. Most browser tests report only idle latency. If yours spikes under load, see bufferbloat explained.
Jitter is computed, not observed
No one measures jitter directly. A test sends a series of small requests, records each latency, and then derives jitter from the series. Tools disagree on the formula: the mean absolute difference between consecutive samples, the standard deviation of all samples, or a smoothed running estimate like the one in RFC 3550. These give different numbers from identical data, so only compare jitter between runs of the same tool. For what jitter does to calls and games, see jitter and packet loss explained.
How BrowserInsight's test does it
As a concrete example, here is what our speed test does, one legitimate design among several:
- Transport: HTTP requests to our own edge endpoint, one stream at a time (sequential, not parallel).
- Warm-up: a roughly 30 KB request whose result is discarded before the download and upload phases.
- Payload sizing: download transfers step from 200 KB to 1 MB to 3 MB, then adapt to about two seconds of transfer, capped at 10 MB. Upload sizes are scaled from the speed of the first 200 KB upload.
- Duration: the download phase continues until it has both 15 seconds and three transfers, stopping at 30 seconds or ten transfers at most; the upload phase makes up to three transfers.
- Timing: each transfer is timed from the moment the request is sent until the last byte arrives (or the upload is acknowledged), so one round trip is included in every sample.
- Headline throughput: the median of the timed transfers in each phase.
- Latency: the mean of three 1 KB HTTP requests, after one discarded primer request.
- Jitter: the mean absolute difference between consecutive latency samples.
The trade-off is plain: a single stream reflects what one connection gets, but can read lower than a multi-stream test on a very fast link. Three latency samples also make the jitter figure coarse; treat it as a quick indication rather than a call-quality verdict. It does not use ICMP, does not run parallel streams, and does not measure latency under load.
A checklist for reading any methodology page
Before trusting a number, look for:
- Streams: one connection or several?
- Duration: a fixed time, or a fixed file size?
- Warm-up: is the ramp-up discarded, and how?
- Aggregation: median, mean, or best run?
- Server distance: where is the test endpoint relative to you?
- Latency definition: idle or loaded, HTTP or ICMP?
A tool that answers these openly is more useful than one with a bigger number.
Frequently Asked Questions
Can a website test my ping with ICMP?
No. Browsers do not expose ICMP or raw sockets to web pages. A browser "ping" is the time of a small HTTP or WebSocket round trip, which includes some server processing.
Why does a speed test download a throwaway file first?
To get past TCP slow start. A fresh connection begins with a small congestion window, so the first bytes move slowly. A warm-up transfer (or discarding the early interval) lets the measurement reflect steady-state throughput.
Is a single-stream test less accurate than a multi-stream test?
Not less accurate, just a different question. A single stream measures what one TCP flow achieves; multiple streams measure the line's total capacity. On a very fast link, a single stream may read lower.
Why is the browser's latency higher than my command-line ping?
HTTP latency includes server processing and connection handling on top of the network round trip, while ICMP ping measures only the latter.
Conclusion
A browser speed test is a timed set of HTTP transfers, shaped by what a web page is allowed to do. Warm-up handling, payload sizing, stream count and aggregation decide the headline number far more than most people expect. Read a methodology page with those in mind, and run our network speed test with the design above in view.
Recommended Reading:
