The Test Sequence
| Step | What Happens | What It Measures |
|---|---|---|
| Server selection | The test picks or suggests a nearby server | Path quality and test endpoint capacity |
| Latency probe | Small messages are timed round trip | Ping and jitter |
| Download test | Data flows from server to device | Downstream throughput |
| Upload test | Data flows from device to server | Upstream throughput |
| Calculation | Samples are averaged and converted to bits per second | Reported Mbps or Gbps |
Server Selection and CDN Edge Proximity
Before any data moves, the test must pick a server. Most tools present a geographically nearby option, but "nearby" means different things to different platforms. Ookla's Speedtest.net maintains a network of ISP-hosted and third-party-hosted servers and picks the one with the lowest latency from a candidate list. Fast.com uses Netflix's CDN edge infrastructure. nperf uses its own distributed network. Cloudflare Speed Test routes to the Cloudflare PoP closest to your IP address.
The server is part of the result. A congested or distant server limits what you can measure. A server inside your ISP's own network will typically show the cleanest number for your access line, while a server that requires transiting a busy peering point may add latency and throughput limits that have nothing to do with your home connection.
The Latency Probe Phase
Before downloading or uploading bulk data, the test sends a series of small probe packets and times their round trips. These measurements produce the idle ping and jitter values. The latency probe runs on a quiet connection, so it captures the best-case latency the path can achieve. This is distinct from loaded latency, which is measured while bulk traffic is flowing and is often significantly higher on connections with large buffers.
Download Mechanics: Parallel TCP Connections and TCP Slow Start
A speed test downloads data by opening multiple simultaneous TCP connections from the test server to your device. Each connection independently ramps up its sending rate using TCP's congestion control algorithm, which starts slowly and increases the rate until it detects packet loss or fills the receive window. This ramp-up phase, called slow start, means a single short-lived TCP connection on a high-latency link may never reach the link's true capacity.
Parallel streams solve this: while one stream is still ramping up, others are already running at full speed. The aggregate throughput of all parallel streams together approaches the true available bandwidth faster than a single connection would. Ookla uses up to 8 parallel TCP connections by default. nperf uses a different approach with more streams. Fast.com uses multiple parallel HTTP/2 streams within fewer connections.
The test samples throughput at regular intervals — often every 100–200 ms — and discards early samples from the slow-start phase. The reported download speed reflects the sustained portion of the transfer, not the initial ramp.
Upload Mechanics: Measuring the WAN Uplink
The upload phase reverses the flow: your device generates test data and sends it to the server. The same parallel-stream logic applies. Your ISP's upload bandwidth is typically much smaller than download on asymmetric plans (cable DOCSIS, DSL, most fixed wireless), so the upload test saturates the uplink more quickly and the results stabilize faster.
Browser-based tests generate upload data in memory rather than reading from disk, so upload speed is not limited by local storage throughput. However, browser JavaScript engines and the browser's own networking stack can introduce CPU overhead that limits measured upload on very fast connections — one reason native app tests sometimes show higher numbers than browser tabs.
Throughput vs Goodput: What You Are Actually Measuring
Throughput is the raw bit rate on the wire, including all protocol headers, acknowledgements, and retransmissions. Goodput is the useful payload data rate — the actual application-level bytes delivered. Every TCP/IP packet carries header overhead: 20 bytes for IPv4, 20 bytes for TCP, plus Ethernet framing. On a gigabit connection, this overhead typically reduces usable payload throughput by 2–5% compared to the raw line rate.
Speed tests measure throughput at the transport layer and report it as Mbps. They do not subtract header overhead, so the reported number is slightly higher than the pure payload goodput your application sees. This is one reason a 1 Gbps plan may show 940–980 Mbps rather than 1,000 Mbps in a carefully controlled test.
Single-Stream vs Multi-Stream Tests
| Tool | Default Streams | Implication |
|---|---|---|
| Ookla Speedtest | Up to 8 parallel TCP streams | Reliably saturates most home connections |
| Fast.com | Multiple HTTP/2 streams, fewer connections | Closer to Netflix delivery behavior |
| nperf | Many parallel streams | Aggressive saturation, may show higher peaks |
| iPerf3 (single stream) | 1 TCP stream by default | Can underestimate capacity on high-latency links |
| iPerf3 (multi-stream) | Configurable with -P flag | Better saturation, used by network engineers |
How ISPs Can Game Speed Test Results
Because speed test server IP addresses are publicly known, an ISP's QoS system can recognize test traffic and assign it elevated priority in the outbound queue. This gives test packets preferential treatment over normal HTTP, video, or gaming traffic — producing measured speeds and latency figures that are better than what everyday applications experience. This practice is not universal and is difficult to prove without controlled comparisons, but it is a documented concern. Testing to a server you control using iPerf3, or comparing results from many different servers, can reveal whether results are consistent across paths.
What a Speed Test Does Not Prove
A speed test measures one path, to one server, at one moment, using one transfer method. It does not prove that every website will load quickly, that game servers will have low latency, that your Wi-Fi is well-configured, or that congestion will not appear at peak hours. It is a useful diagnostic snapshot, and running it correctly removes local variables — but it is the beginning of network troubleshooting, not the end.
Frequently Asked Questions
Does a speed test download a real file?
Usually it transfers generated test data held in memory rather than an actual stored file. The goal is to move as much data as possible during a timed window, not to retrieve a specific document.
Why do speed tests use multiple connections?
A single TCP connection may not fill a fast link due to TCP slow start and congestion control ramp-up. Parallel streams reach peak throughput faster and produce a more accurate result for the short duration of a test.
Why do different speed tests show different results?
Different tools use different servers, routing paths, numbers of parallel streams, test durations, sampling methods, and calculation rules. ISP traffic shaping, local Wi-Fi conditions, and background processes on the test device also contribute. Run at least two tools to the same nearby server and compare before drawing conclusions.