How Does a Speed Test Work?
An internet speed test measures four things - download, upload, ping and jitter - by sending timed packets to a nearby server. The interesting part is how each tester chooses what to measure and against which server.
What a speed test actually does
When you tap "go" on a speed test, your browser opens a connection to the nearest test server and runs four short tests in sequence. Each one takes 5-15 seconds, so the whole thing typically completes inside 30 seconds.
- Ping - sends a tiny packet to the test server and times the round-trip. The tester usually averages 5-10 pings to smooth out noise. Lower is better; under 20 ms is excellent on local SA traffic.
- Jitter - the variance across those same pings. See our jitter guide for why this matters more than ping itself for VoIP and gaming.
- Download - pulls multi-megabyte files in parallel TCP streams and measures throughput across all of them. Most modern testers open 4-8 parallel streams because a single TCP stream can't saturate a fibre line (slow-start + congestion control hold it back).
- Upload - sends data the other way using the same parallel-stream technique. On symmetric fibre, upload should match download.
Under the hood: TCP streams and warm-up
The reason a 10-second download test is the floor, not the ceiling, is TCP slow-start. When a new connection opens, TCP doesn't blast traffic immediately; it ramps up the window size over the first few seconds, watching for packet loss to tell it when the line is saturated. On a 1 Gbps fibre line this ramp can take 3-5 seconds per stream - so a one-second test barely measures anything useful.
The standard tester architecture works around this in three ways:
- Parallel streams. Opening 4, 8 or 16 TCP streams in parallel means the aggregate throughput climbs faster than any single stream can. Each individual stream is still in slow-start, but together they fill the pipe within 1-2 seconds.
- Warm-up window. Most testers discard the first 1-2 seconds of the test entirely. Only the steady-state throughput counts toward your reported number. This is why the dial on Ookla sweeps up and back down - the bottom section of the dial is the warm-up; the peak is the reported value.
- Chunked download. Rather than pulling one giant file, the tester requests many small chunks (typically 1-8 MB each) in a tight loop. This smooths out brief network jitter and keeps the streams busy for the whole test window.
The same logic runs in reverse for upload. The reason upload measurements often feel less stable than download is that consumer TCP stacks (Windows, macOS, iOS, Android) are tuned for download and are noisier under upload-heavy load.
Server selection: why your pick of server matters
Every tester needs a server to push and pull data against. The server's network position relative to you sets the floor on what the test can ever measure. Three things matter:
- Geographic distance. A test from Cape Town against a JHB server adds ~25 ms to ping by physics alone (the fibre run is ~1,400 km). Against a London server it adds ~150 ms. Throughput is unaffected for short distances but starts to suffer once the round-trip exceeds the receive-window-divided-by-RTT ceiling - i.e. you can't actually pull 1 Gbps from a New York server even if the line could carry it.
- Server network. A test against a server hosted on Openserve's network from an Openserve line stays inside Openserve. Same for Vumatel. This isolates the FNO's network from any peering / transit issue and gives you the truest reading of the physical line. The Openserve-SAIX, Vumatel and Frogfoot servers in Ookla's pool are all there for this purpose.
- Server capacity. A poorly provisioned community server might itself be the bottleneck. The major tester networks (Ookla, Cloudflare, Netflix, Akamai) provision their pop sites for 100+ Gbps to make sure the server is never the slow part.
Ookla picks the server with the lowest ping to you by default - which is a good heuristic but isn't always the right answer. If you want to test how your line performs to Netflix specifically, run Fast.com (it tests against Netflix's CDN). If you want to test how your line performs to most local SA services, pick a NAPAfrica-hosted server. If you want to test your ISP's peering on a known clean international path, pick a Cloudflare server.
Why Speedtest.net and Fast.com disagree on the same line
Running both back-to-back on the same fibre line routinely returns different numbers. That's not a bug; it's the methodologies pulling in different directions.
- Ookla / Speedtest.net. Opens 8 parallel TCP streams to the nearest server (chosen by ping). Reports the peak steady-state throughput across all streams. Designed to measure the absolute capacity of the line - which is why it almost always reports higher numbers than other testers.
- Fast.com (Netflix). Streams real video bytes from Netflix's Open Connect CDN. Reports a sustained "real-world" download number that's closer to what you'd actually achieve while streaming. Often 10-30% lower than Ookla because it's pulling from a single CDN node, not parallel streams across multiple servers, and because Netflix CDN nodes are sometimes congested at peak.
- MyBroadband / Speedtest.co.za. Both anchor against SA-hosted servers, which makes ping much more representative of how a typical SA user experiences local sites. Throughput numbers are usually similar to Ookla but vary by which specific server is picked.
- OpenSpeedTest. Pure HTML5, no Flash/Java fallbacks. Lower browser overhead means more accurate readings on slow lines where the browser itself can be a bottleneck.
- Cloudflare Speed Test. Tests against Cloudflare's global edge, one of the best-peered networks in the world. A clean way to isolate your ISP's peering quality - if Cloudflare is fast but Ookla is slow, the issue is somewhere between your ISP and the Ookla server, not on your line.
None of them is "wrong"; they're answering different questions. Running three testers across three methodologies (one parallel-stream capacity tester, one CDN real-world tester, one local SA latency tester) gives a much truer picture of the line than a single Ookla number does.
Which tester is best for which use case
We list seven testers on our SA speed test page because none of them is best at everything. The right tool depends on the question:
- "Am I getting the speed I'm paying for?" - Ookla. Pick the Openserve, Vumatel or Frogfoot server matching your line's FNO. This isolates the physical line from peering.
- "Will Netflix or Showmax stream smoothly?" - Fast.com. It's the only tester pulling from the same CDN that delivers your video.
- "Why does everything feel laggy?" - MyBroadband or Speedtest.co.za for SA ping; the speed-test on this site for combined jitter + ping + throughput in one view. Look at jitter, not just ping.
- "Is my ISP's peering bad?" - Run Cloudflare's speed test (clean international peering) and an Ookla test (closest local server) back-to-back. If Cloudflare is materially faster, the issue is local peering not the line.
- "Testing a flaky mobile signal in the back garden" - Speed Test Master or OpenSpeedTest. Both are mobile-optimised and finish in under 30 seconds, which matters when you're holding a phone in the wind.
- "On a slow line where every Mbps matters" - OpenSpeedTest. Its HTML5-only architecture has lower browser overhead, which on a 5-10 Mbps line can mean a 10-15% truer reading than a heavier tester.
- "Settling a dispute with the ISP" - Run Ookla three times at different times of day, wired, and screenshot each result. ISPs accept Ookla reports as evidence in escalation tickets; they don't always accept Fast.com or third-party testers.
Reading the results
- Download (Mbps): how fast you can pull data in. Wired, on a clean network, you should see at least 80% of your line speed - and at peak hour no less than 50%.
- Upload (Mbps): how fast you can push data out. Most SA fibre packages from Vumatel Core and Openserve are symmetric or near-symmetric, so upload should be similar to download.
- Ping (ms): how responsive your line feels. Under 20 ms is excellent against an SA server; under 10 ms is what a clean fibre line delivers.
- Jitter (ms): stability of your ping. Under 5 ms is excellent; over 30 ms will be audible on voice calls. See our jitter guide for the SA-network numbers.
- Packet loss (%): not all testers show this. Anything above 1% in a 30-second test is meaningful and usually means a physical-layer problem - faulty fibre patch, weak Wi-Fi, or a saturated upload pipe.
Why your results vary
Same line, two tests, two different answers? That's normal. Common reasons in rough order of frequency:
- Wi-Fi vs Ethernet. Wi-Fi caps the test at the slower of your router and signal strength. A 1 Gbps line tested over a Wi-Fi 5 router from two rooms away will report 150-300 Mbps. Plug into the router with a Cat 6 cable to test the line itself.
- Time of day. SA peak hour is 19h00-22h00. Many ISPs and FNOs contend on backhaul during this window. A test at 14h00 and one at 20h00 can return materially different numbers on the same line.
- Another device using bandwidth. A Steam update, a 4K Netflix stream, an iCloud backup or a Sonos updating firmware all cut into the speed test result. Quiet the network first.
- Test server load. A community-hosted server might be saturated itself. Re-run with a different server if a result looks suspicious.
- Browser overhead. A laptop with 80 tabs open and a CPU thrashing the test result. Quit other heavy apps; an old laptop especially can cap a 500 Mbps+ line just because the JS engine can't keep up.
For a meaningful test: wired, idle network, three runs across two testers, average the result. Anything else is a noisy reading. Our in-house SA speed test hosts servers in Johannesburg and Cape Town for the most accurate local result.
Frequently asked questions
Ready to upgrade?
Free standard install, free Wi-Fi router and uncapped speeds via Webafrica, South Africa's #1 Netflix-ranked ISP.