Latency
Latency vs bandwidth: why a fast connection can still lag
Short answer: bandwidth is how many bits per second your connection can carry; latency is how long one small message takes to get there and back. Web pages, games and calls are mostly limited by latency, and the latency that hurts most is not the idle ping a speed test shows first but the latency under load: how much the delay grows while something else in the house is downloading or uploading. When that jump is large, the cause is usually bufferbloat, and the fix is a router setting, not a faster plan.
Measure idle and loaded latency now
Two different numbers, two different jobs
| Bandwidth (throughput) | Latency (round-trip time) | |
|---|---|---|
| Unit | Mbps or Gbps | milliseconds (ms) |
| What it limits | How long a big file, a 4K stream or a backup takes | How quickly a click, a game action or a spoken word reaches the other side |
| Typical problem it explains | "The 80 GB game takes all evening" | "The call has a delay", "enemies teleport", "pages hang before loading" |
| Does a faster plan fix it? | Usually yes | Rarely; distance, Wi-Fi and queues dominate |
A rough analogy: bandwidth is the number of lanes on a road, latency is the travel time from one end to the other. Adding lanes does not shorten the road, and it does nothing about a traffic jam at the on-ramp, which is where bufferbloat lives.
Why latency rises when the line is busy
Every router and modem holds a queue (a buffer) of packets waiting to be sent. Some queueing is normal and useful. The IETF's own recommendations on queue management say that queueing "occurs whenever the arrival rate of data at the ingress to a device exceeds the current egress rate" and that "excessive queueing can lead to unwanted delay" (RFC 7567, IETF Best Current Practice). When a large download or upload fills an oversized buffer, every other packet, including your game update or the next slice of your voice, waits behind it. Idle ping can be 15 ms while ping during the download is 150 ms or more.
The ndt7 protocol our test uses reports the server's view of round-trip time throughout the transfer, and its specification notes that a growing RTT during the test indicates a bottleneck with a large buffer (ndt7 protocol spec, M-Lab). That is why our result shows two latency figures: idle latency before the transfer and latency under load during it.
How to read your two latency numbers
| Increase under load | What it usually means | What you will notice |
|---|---|---|
| Under about 30 ms | Queues are well managed | Calls and games stay smooth while others download |
| About 30–100 ms | Moderate buffering | Occasional rubber-banding in games, slight call delay during big transfers |
| Over 100 ms | Bufferbloat | Calls freeze or talk over each other; games lag whenever someone uploads photos or a backup runs |
These bands are our reading guide, not an industry standard; the direction matters more than the exact cut-off. Run the test twice: once with the house quiet and once while another device streams or uploads. If the loaded figure only explodes in the second run, the queue is the problem.
A real example
A developer documented gaming lag on a 219.7/42.2 Mbps cable connection in April 2026: idle latency was 20 ms, but it rose by 78 ms during downloads, with a worst case of 374 ms, earning a "C" on the Waveform bufferbloat test. A Wi-Fi 7 router's built-in QoS made it worse; turning on Smart Queue Management (SQM) in OpenWrt brought the grade to "A" (Matt McCarthy, "Diagnosing bufferbloat gaming lag"). The download speed barely changed. The lag disappeared.
How to fix high latency under load
- Find which direction bloats. If latency jumps mainly during upload, a photo sync, cloud backup or video upload is the usual trigger, and cable connections with small upload capacity are most affected. See why upload is often the bottleneck.
- Turn on SQM or "Smart Queue". Look for SQM, Smart Queue, fq_codel or CAKE in your router settings. OpenWrt's own guide tells you to measure your speeds on an idle line and then set the SQM download and upload limits to 90% of those results, so the queue forms in your router, where it is managed, instead of in the modem (OpenWrt SQM guide). The same guide documents a 500/35 Mbps cable line whose latency increase under load "dropped to zero" with CAKE at 90%.
- Be careful with "gaming QoS" presets. Prioritising a device is not the same as managing the queue; as the example above shows, some presets make loaded latency worse. Test before and after.
- Rule out Wi-Fi. A weak 2.4 GHz link adds its own delay and retries. Repeat the test on a cable; if loaded latency is fine there, the fix is router placement or a better band, not SQM.
- Schedule the heavy jobs. If your router has no queue management, moving backups and console updates to the night does the same job by hand.
When latency is high even when the line is idle
A high idle figure is a different problem: distance to the server, a satellite or cellular link, or a congested route. Bufferbloat fixes will not help. For games, test the latency to the game's own servers rather than to the nearest speed test server; our ping test guide for gaming shows how. For calls, compare your figures with what Zoom, Teams and Meet need.
Related
How we measure latency under load · Why results vary between tests · What ping means for gaming · Household bandwidth calculator