# Comparing speed tests

Most speed tests give you three numbers: download, upload and ping. For “am I getting what I pay for?” that is enough. For “why does this feel slow?” it almost never is.

Below is, per metric, what it tells you, what goes wrong if you do not measure it, and how PulseSpeed measures it.

## What a complete connection assessment measures

| Metric | What it tells you | What goes wrong without it | How PulseSpeed measures it |
| --- | --- | --- | --- |
| Download | How fast you can receive data. | Slow downloads, buffering while streaming. | Multiple parallel streams, averaged over the full measurement. |
| Upload | How fast you can send data. | Slow cloud backups, poor video quality others see of you. | Multiple parallel streams, server streams without buffering. |
| Ping (idle) | Response time of your line at rest. | Delay in games and calls. | 12 probes, two highest outliers discarded. |
| Jitter | How unevenly packets arrive. | Robotic audio, stuttering video despite low ping. | Mean absolute difference between consecutive measurements. |
| Packet loss | Percentage of packets that vanish. | Dropped words, frozen video. | Failed probes are counted and reported separately. |
| Bufferbloat | How far latency climbs once the line is loaded. | Calls stutter the moment someone downloads. The most underestimated cause. | Ping measured during active downloads; graded A to F on the increase. |
| Bidirectional load | Behaviour when sending and receiving at once. | Video calls fail while every individual metric looks fine. | 3.5 Mbps up and down simultaneously, 13 seconds. |
| Long-run stability | Whether your line holds up over time. | Dropouts and evening congestion a 20-second test never sees. | 300 measurements over 5 minutes, one per second. |
| MOS estimate | Expected call experience on a 1 to 5 scale. | Raw numbers with no bearing on your actual experience. | ITU-T G.107 E-model over measured latency, jitter and loss. |
| IPv6 | Whether modern addressing works for you. | Unreachable services, unnecessary detours. | Separate connectivity test. |
| MTU | Largest packet that fits without fragmentation. | Unexplained slow or stalling connections. | Increasing payload sizes until fragmentation occurs. |
| DNS | Which resolver you use and what it returns. | Slow name resolution, unwanted visibility. | Resolver detection plus lookups for A, AAAA, MX, TXT and NS. |

## Why bandwidth is rarely the problem

Microsoft states that a one-to-one Teams video call runs at recommended quality on 1.5 Mbps in both directions, and that HD can be delivered under 1.5 Mbps. Google lists up to 1.7 Mbps for 720p and up to 3.6 Mbps for 1080p on Meet. Those are modest figures: virtually any modern connection clears them comfortably.

Yet video calls stutter everywhere. Not because bandwidth is missing, but because latency, jitter and packet loss degrade the moment something else happens on the line. That is exactly why PulseSpeed tests at 3.5 Mbps per direction — well above the recommended figures — and focuses on what happens to your latency while that traffic runs.

Sources for the figures above: Microsoft Learn, Prepare your organization's network for Teams, and Google Workspace Admin Help, Prepare your network for Meet meetings & live streams. Both retrieved in August 2026. We reproduce these figures from vendor documentation and do not independently verify them.

## What PulseSpeed does not do

An honest comparison names the limits too. PulseSpeed does not do the following:

- We do not pick a measurement server for you and offer no server list. You always measure against the nearest node of a globally distributed network.

- We store no results on our servers. That means no history across multiple devices or months — your history stays in one browser.

- There is no mobile app. The test runs in the browser, including on mobile, but then partly measures browser overhead.

- We do not measure mobile coverage, signal strength or carrier league tables.

- For raw peak throughput on very fast lines (multiple Gbps) a browser-based test is inherently limited; the browser hits its ceiling before your line does.

## Frequently asked questions

### Which speed test is best?

It depends on what you want to know. If you only want to verify you get the advertised throughput, any major speed test does that well, and tests with their own global server network have the longest track record there. If you want to know why your connection feels slow while the speed looks fine, you need measurements most tests skip: bufferbloat, behaviour under simultaneous load, and stability over time. That is what PulseSpeed is built for.

### What is the most extensive speed test?

Extensive means both the number of distinct metrics and whether they are measured under realistic conditions. PulseSpeed measures twelve: download, upload, idle ping, jitter, packet loss, bufferbloat, behaviour under bidirectional load, stability over 5 minutes, a MOS estimate, IPv6, MTU and DNS. The full method is publicly documented so you can check every figure.

### Which speed test measures bufferbloat?

PulseSpeed measures bufferbloat by default on every run: after the upload measurement, ping is measured again while downloads are running. The difference between idle and loaded ping is the bufferbloat, graded from A (under 5 ms increase) to F (over 200 ms). Dedicated standalone bufferbloat tests also exist that measure only this.

### Is a higher download always better?

No. Above roughly 100 Mbps, extra bandwidth makes little perceptible difference for most households, while latency and stability immediately do. A stable 50 Mbps line at 15 ms ping with no bufferbloat feels faster than a gigabit line that collapses to 300 ms under load.

### Why does my result differ from another speed test?

Different tests pick different servers, durations, numbers of parallel connections and averaging methods. Some also report in binary megabits. PulseSpeed reports decimal megabits (1 Mbps = 1,000,000 bits per second) and documents every choice on the methodology page. Differences of 10 to 20 percent between tests are normal; a factor of two points at something else, usually WiFi.

### Can I use the result to complain to my ISP?

Yes, with one condition: measure over an ethernet cable, not WiFi. An ISP can legitimately dismiss a WiFi measurement. Measure at several times of day, including between 7 and 10 PM, and keep the stability test — it shows dropouts a snapshot misses.