How Internet Speed Tests Actually Work (And Why Results Vary So Much)

When your Netflix buffers, your Zoom call freezes, or downloads crawl, the first instinct is often: “Let’s run a speed test.” But have you ever wondered what those big download/upload numbers and the little ping figure are actually telling you?

In this article we’ll break down the core mechanics of how internet speed tests work in 2025, what they’re really measuring, why you get different results from different sites, and some lesser-known factors like bufferbloat that can make your connection feel slow even when the headline speed looks great.

The Three Main Numbers: Download, Upload, and Ping

Most speed tests report three core metrics:

Download speed — How fast data can travel to your device (Mbps or Gbps). This matters for streaming, browsing, gaming downloads, etc.
Upload speed — How fast data can travel from your device. Critical for video calls, cloud backups, live streaming.
Ping (latency) — How long it takes for a small packet to make a round trip to the test server and back (usually in milliseconds). Lower is better for gaming, VoIP, and real-time apps.

A typical test flow looks like this:

Initial handshake / latency measurement — The client sends small “hello” packets (often 1–10 KB) multiple times to measure round-trip time (RTT). Median or lowest stable value becomes your ping.
Download phase — The test client requests increasingly large chunks of random (or compressible) data from the server. Modern tests use multiple parallel HTTP/TCP connections (threads) to saturate your connection.
Upload phase — Your device generates and sends large random data blobs back to the server.
(Optional) Loaded latency — Some tests (Cloudflare, Waveform, DSLReports legacy style) ping during heavy up/download to detect how much latency spikes under load.

The final speed is calculated as:

Throughput = total bytes transferred / effective time

(The “effective time” subtracts server processing delays when possible.)

How Download & Upload Phases Really Work

Modern speed tests avoid just dumping one giant file. Instead they use adaptive techniques:

Start small (e.g., 100 KB – 1 MB chunks) to estimate your speed quickly.
Ramp up: If you’re fast, request bigger and bigger payloads (up to tens or hundreds of MB total).
Use multiple TCP connections (usually 2–8 threads) to overcome per-connection limits and TCP window scaling issues.
Run for a fixed time (e.g., 10 seconds) rather than fixed size, so very fast connections don’t take forever.

Examples from popular tests in 2025:

Ookla Speedtest → Multi-threaded TCP/HTTP, adaptive sizing, focuses on max throughput.
Cloudflare Speed Test → Emphasizes quality + realism; doesn’t fully saturate; measures responsiveness under various loads.
FAST.com (Netflix) → Simple, download-focused, uses Netflix edge servers.
M-Lab/NDT → Single-stream + multi-stream variants, academic-grade, often “off-net” to simulate real Internet paths.

Why You Get Different Results on Different Sites

It’s frustrating but normal. Here are the biggest reasons:

Factor	Impact on Results	Example Difference
Server location	Closer = lower latency, often higher speed	NYC → NJ vs NYC → Singapore: 20–60% variance
Number of threads	More threads → better saturation on high-speed links	Single-stream vs 4–8 threads: up to 2× difference
Test duration & ramp-up	Short tests favor bursty connections	5 s vs 20 s: can differ 10–30%
On-net vs off-net	On-net (ISP internal) often looks faster	ISP server vs distant CDN: 10–50% higher
Loaded vs unloaded latency	Many tests ignore bufferbloat	Unloaded ping 12 ms → loaded 400 ms
Device, Wi-Fi, browser limits	Wi-Fi overhead, old browser thread limits	Phone vs wired PC: 20–80% lower

Bufferbloat: The Hidden Killer

Even with 1 Gbps download and 10 ms ping, your connection can feel terrible during uploads/downloads.

Bufferbloat happens when routers (or ISP equipment) have overly large buffers. When the link gets congested, packets sit in those giant queues instead of being dropped early. This creates:

Massive latency spikes (100–2000 ms)
Jitter (variable delay)
Poor responsiveness for gaming, video calls, browsing

Why it matters for speed tests:

Many basic tests only measure unloaded ping. Real-world use is loaded. Tests like Cloudflare, Waveform’s bufferbloat tool, or Flent RRUL show how latency explodes under full load.

Quick test for bufferbloat

Run a good speed test → note baseline ping → start a big upload/download → run pings (e.g. ping google.com) at the same time. If latency jumps >50–100 ms, you likely have bufferbloat.

Fixes include routers/firmware with Smart Queue Management (SQM) like fq_codel, CAKE, PIE — many modern mesh systems (eero, some Ubiquiti) now support this.

Tips for More Accurate Results in 2025

Use Ethernet instead of Wi-Fi whenever possible.
Close all other apps/devices using bandwidth.
Test at different times of day (avoid peak evening hours).
Try multiple tests: Ookla, Cloudflare, M-Lab, FAST.com.
For realism, look for tests that measure loaded latency or “responsiveness under load.”
Repeat 3–5 times and take the median (outliers happen).

Speed tests are snapshots, not perfect science. They help diagnose whether your ISP is roughly delivering what you pay for — but real-world experience depends on routing, peering, home network, and yes… bufferbloat.

In the next article we’ll dive into building our own privacy-first speed test and how we handle accurate timing at the edge.

What speed test do you trust most, and have you ever chased down bufferbloat? Drop a comment below!