What "Bandwidth" and "Latency" Actually Mean (and Why Your Wi-Fi Lies)
Contents
I upgraded to a gigabit connection years ago expecting video calls to stop stuttering, and they didn’t, because video calls were never a bandwidth problem in the first place. That’s the trap almost everyone falls into with home networking: the number on the ISP’s marketing page, the one you’re paying for, measures a completely different thing to the one actually causing the video call to freeze mid-sentence. Bandwidth tells you how much data can move per second. Latency tells you how long a single piece of data takes to get there and back. A connection can be enormous in the first sense and terrible in the second, and most of the “internet feels slow” complaints I’ve diagnosed over the years turn out to be exactly that.
The pipe analogy, done properly
Bandwidth is usually explained as the width of a pipe — a gigabit connection is a wide pipe, a hundred-megabit connection is a narrower one, and more water fits through the wide one per second. That’s a reasonable starting point, but it misses the part that actually matters for how a connection feels: latency is how long it takes a single drop of water to travel the length of the pipe, not how much water fits through it. A pipe can be enormously wide and still take a long time for the first drop to arrive at the far end, if the pipe itself is very long, and that length — the physical and routing distance a packet has to travel — is most of what determines latency, independent of how wide the pipe is.
This is why a gigabit connection doesn’t fix video call stutter: the video call isn’t waiting for a large volume of data to arrive, it’s waiting for each small packet to arrive quickly and in order, many times a second. Bandwidth measures throughput over time. Latency measures the delay before any of that throughput starts arriving. A large file download cares almost entirely about the first. A video call, a game, or a voice call cares almost entirely about the second, and doubling your bandwidth does essentially nothing for it.
Measuring both properly
Most people run a single speed test and treat the number as the whole story, when the useful diagnostic actually needs two separate readings.
| |
The average round-trip time is the latency figure most people quote, but the number worth actually paying attention to is the spread between the minimum and maximum — that single 41.6ms reading against a 13.8ms floor is jitter, and jitter is what breaks a video call, not the average latency. A connection with a consistent 60ms round trip is far more usable than one averaging 20ms but occasionally spiking to 200ms, because real-time protocols can tolerate a stable delay far better than an unpredictable one — the receiving end can buffer for a known, steady delay, but a buffer sized for 20ms falls over completely the moment a packet takes 200ms instead.
Why Wi-Fi specifically lies about this
A wired ethernet connection behaves close to deterministically — the same cable, the same latency, every time, because it’s a dedicated physical path with no other device competing for it. Wi-Fi is a shared radio medium, which means every device on the network is taking turns transmitting on the same channel, and that turn-taking is where Wi-Fi’s specific dishonesty comes from: the connection can advertise an enormous theoretical bandwidth figure on the box (the “AX3000” or “AC1900” style numbers) while delivering wildly inconsistent real-world latency, because that number describes the radio’s peak theoretical throughput under laboratory conditions, not what happens when your microwave, your neighbour’s router, and three other devices in the house are all contending for the same 2.4GHz channel at once.
Distance and obstruction make this worse in a way bandwidth numbers don’t capture at all. Signal strength degrades with distance and walls, and as it degrades, the radio drops to a more robust but slower modulation scheme to keep the connection alive — which means the same device, in the same room, can see its actual achievable bandwidth swing by an order of magnitude depending on exactly where it’s standing, while the router’s advertised maximum number never changes on the box. None of this shows up in a single speed test taken standing next to the router, which is exactly where most people run the test that convinces them their Wi-Fi is fine.
What actually causes the stutter, ranked by how often I’ve seen it
- Channel contention from neighbouring networks, especially on 2.4GHz in dense housing, where dozens of routers are all fighting for the same handful of non-overlapping channels. Switching to 5GHz or 6GHz, where available, sidesteps most of this simply because fewer neighbouring devices are using those bands yet.
- Bufferbloat, where a router queues packets during a burst of traffic (a large upload, a big download) instead of dropping or prioritising them, adding hundreds of milliseconds of latency to everything else sharing the connection until the queue clears. This is invisible in a bandwidth test and devastating for anything real-time running alongside a large transfer.
- Physical interference from anything sharing the 2.4GHz band — microwaves, some cordless phones, certain baby monitors — which doesn’t show up as reduced bandwidth so much as intermittent packet loss and latency spikes exactly when the interfering device is active.
- Too many devices on one access point, particularly older ones that handle client scheduling poorly under load, where each additional connected device takes a slightly larger slice of airtime regardless of whether it’s actively transmitting.
The maths ISPs would rather you not do
There’s a third figure that connects bandwidth and latency together, and it’s the one that explains why a technically-fast connection can still feel laggy under load: bandwidth-delay product, which is roughly the amount of data that can be “in flight” on a connection at any given moment before the sender needs an acknowledgement back. A high-bandwidth, high-latency connection — a satellite link is the extreme example, but a congested Wi-Fi network exhibits a milder version of the same thing — has a large bandwidth-delay product, meaning a lot of data can be sent before the first acknowledgement comes back, which is exactly the condition that lets a router’s buffer fill up and start adding the queueing delay that shows up as bufferbloat. This is why fixing bufferbloat isn’t about increasing bandwidth at all; it’s about managing how much is allowed to queue before it starts hurting everything sharing that connection.
Home routers rarely expose this concept directly, which is part of why it stays invisible to most people troubleshooting a “slow” connection. The advertised bandwidth number is real, measured under ideal conditions, and technically true. It just doesn’t predict what the connection feels like the moment two things are competing for it, because feel is a latency-and-jitter story, not a throughput story, and the box the router came in never mentions either.
A worked example: two connections, same bandwidth test result
Consider two home connections that both report 500 Mbps down on a speed test, run standing next to the router. The first is a wired connection to a router two metres away with nothing else transmitting; round-trip latency to a nearby server sits at a steady 12ms, and it barely deviates under load. The second is a Wi-Fi connection three rooms away, sharing the 2.4GHz band with four other households’ routers and a microwave that runs twice a day; it also hits 500 Mbps on a clean test, but round-trip latency swings between 15ms and 180ms depending on exactly when the test runs, and a video call on that connection drops frames every few minutes for no reason anyone in the room can point to.
Nothing about the bandwidth figure distinguishes these two situations, because the test that produced “500 Mbps” for both of them measured a burst of sustained throughput over a few seconds, under whatever conditions happened to exist at that exact moment — it didn’t measure consistency, and consistency is the entire difference between a connection that feels solid and one that feels flaky. This is precisely why a router’s spec sheet number and a single speed test result are both close to useless for diagnosing “why does this feel slow,” and why the fix for the second connection lies entirely in getting closer to the access point, changing channels, or moving to a less congested band, regardless of what plan is on the account.
Troubleshooting a connection that “should” be fine
Speed test looks perfect, video calls still stutter. Run a continuous ping to a stable target (your router’s gateway address, then a public DNS server) for a few minutes while reproducing the problem, and watch for spikes rather than the average — a speed test measures throughput over a short burst and will not reveal jitter that only appears under sustained real-world load.
Wired devices are fine, Wi-Fi devices aren’t. This almost always points at the radio layer specifically — channel contention, distance, or interference — rather than anything upstream of the router, since the wired path proves the ISP connection and the router’s routing are both healthy.
Everything is fine until someone starts a large upload or download. This is the classic bufferbloat signature. Enabling Smart Queue Management or a similar QoS feature on the router, where available, fixes it by allowing the router to prioritise small, latency-sensitive packets over bulk transfer traffic instead of processing everything strictly first-in-first-out.
Latency is consistently high even wired, straight into the router. At that point the problem has moved upstream of your own network, and the next step is checking with a DNS lookup timing test and a traceroute to see which hop between you and the destination is actually adding the delay, rather than assuming it’s local.
One specific device is worse than every other device on the same network. Check that device’s negotiated Wi-Fi standard and signal strength specifically rather than assuming a network-wide problem — an older device that only supports an earlier Wi-Fi standard, or one sitting at the edge of range behind an extra wall, will see materially worse latency and throughput than a newer device standing right next to the access point, even on an otherwise healthy network.
Which number to actually care about
For a file transfer, backup job, or streaming a pre-buffered video, bandwidth is what matters and the ISP’s marketing number is a reasonable proxy for it. For anything interactive — video calls, gaming, remote desktop sessions, voice — latency and its consistency matter far more, and no amount of extra bandwidth fixes a problem that’s actually about queueing, contention, or physical radio conditions. If you’re troubleshooting a “slow internet” complaint and the bandwidth test comes back fine, stop looking at bandwidth. The actual answer is almost always sitting in the jitter, and getting your network genuinely isolated — a guest network that’s actually isolated from your main devices — removes an entire category of contention you didn’t know was competing with you in the first place.
Related Content
