Three different numbers get lumped together as "internet speed." Only one of them is fixed by the laws of physics — and it's usually the one making the call feel laggy.
When a video call stutters or a game feels delayed, the instinctive fix is to buy a bigger internet plan. Sometimes that helps. Often it does nothing at all, because "slow" can mean three completely different things: how long a single piece of data takes to make the round trip (latency), how much data the connection could theoretically carry per second (bandwidth), and how much data it is actually moving right now (throughput). Bandwidth is the one thing an ISP can sell you more of. Latency, for a given destination, mostly isn't for sale at any price — and it turns out to be the thing that governs whether a connection feels responsive.
Latency is the time delay for one piece of data to travel from sender to receiver — usually measured as round-trip time (RTT) with a tool like ping. It's set almost entirely by two things: propagation delay — the actual physical distance the signal has to travel over the cable, fiber, or wireless path, divided by the speed the signal moves at (roughly two-thirds the speed of light in fiber) — and smaller processing/queuing delaysadded at every router and switch along the way. A round trip between New York and Sydney (about 16,000 km each way) has a theoretical propagation floor around 160 ms before a single router even looks at the packet; real-world pings on that path commonly land in the 250–300 ms range once routing and queuing are added. Buying a bigger plan cannot lower that floor, because it doesn't change the distance the signal has to travel.
Bandwidth is the maximum theoretical data-carrying capacityof a connection — the "1 Gbps" printed on the internet plan. It's a ceiling on how much data could move per second under ideal conditions. It is not a promise about what is being achieved right now, any more than a highway's posted speed limit is a promise about today's traffic.
Throughput is the actual, real-world transfer rate being achieved at a given moment — always less than or equal to the bandwidth ceiling. Congestion, packet loss and retransmission, and protocol overhead can all pull throughput below that ceiling. So can latency itself: protocols like TCP cap how much unacknowledged data can be "in flight" at once (the receive window), and that window fills up faster — relative to the available bandwidth — the longer the round trip takes. This is the bandwidth-delay product: a real, well-documented mechanism by which high latency directly throttles achievable throughput, even when bandwidth is generous.
Now widen the pipe and move the destination to the opposite side of the planet — a fast plan, but a genuinely long physical path (or a satellite link, which adds its own propagation delay to space and back). The bandwidth ceiling goes up dramatically. The round trip, set by distance, goes up too — and TCP can only keep a limited amount of unacknowledged data in flight before it has to pause and wait for an acknowledgment. At a long RTT, that window empties and refills far less often per second than at a short RTT, so the connection can spend most of its time waiting rather than sending — capping throughput well below the pipe's real capacity, no matter how wide the pipe is.
TCP limits how much unacknowledged data can be "in flight" at once — its receive window. The maximum throughput a single connection can sustain is roughly window size ÷ round-trip time. With a default 64 KB (524,288-bit) window and a 280 ms RTT, that ceiling is about 524,288 ÷ 0.28 ≈ 1.9 Mbps — regardless of whether the link underneath is rated for 500 Mbps or 50 Gbps. This is the bandwidth-delay product: the amount of data that can be "in the pipe" at any instant is bandwidth × delay, and if the window can't hold that much in flight, the extra bandwidth simply goes unused. Modern operating systems use TCP window scaling and can negotiate much larger windows, and techniques like parallel connections, larger initial windows, or protocols such as QUIC/HTTP-3 can claw back a lot of that lost throughput on long, fast paths — but none of them touch the 280 ms round trip itself. That number is fixed by distance and the speed of light, full stop.
False, or at least badly incomplete. A "laggy" or unresponsive-feeling connection — a video call that stutters, a game where inputs feel delayed — is very often a latency problem: a physical, distance-and-path-based propagation delay that more bandwidth does absolutely nothing to reduce. Bandwidth determines the theoretical ceiling on data volume. Felt responsiveness for interactive, real-time applications is governed by latency — a fundamentally different property of the path, with fundamentally different fixes: a shorter or better-routed network path, a server or CDN edge physically closer to the user, or a protocol better suited to the situation. None of those fixes is "buy more bandwidth,"and buying more bandwidth doesn't substitute for any of them. The reverse case is also real: a low-latency connection struggling with large file downloads genuinely can benefit from more bandwidth. Diagnosing which problem you actually have — latency or bandwidth/throughput — is the practically important step, because the two fixes don't overlap.
Explains why latency (a time delay set by physical distance and per-hop processing), bandwidth (a theoretical capacity ceiling), and throughput (actual achieved transfer rate) are three genuinely different quantities — and why a higher-bandwidth internet plan doesn't always fix a laggy, unresponsive-feeling connection, illustrated with the bandwidth-delay product.
Latency is the time delay for a single piece of data to travel from sender to receiver, commonly measured as round-trip time (RTT) via ping. It's governed almost entirely by propagation delay — the physical distance the signal travels through cable, fiber, or air, divided by the signal's real propagation speed (roughly two-thirds the speed of light in fiber) — plus smaller processing and queuing delays added at each router or switch along the path. Because the distance component doesn't change when you upgrade your internet plan, a connection to a server on the far side of the planet has a real, physics-imposed minimum latency no amount of additional bandwidth can reduce.
Bandwidth is the maximum theoretical data-carrying capacity of a connection — the number printed on an internet plan, such as "1 Gbps." It describes how much data could move per second under ideal conditions. It says nothing about how much data is actually moving at any given moment; that is throughput.
Throughput is the real, observed transfer rate on a connection at a given moment, and it is always less than or equal to the bandwidth ceiling. Network congestion, packet loss and retransmission, and protocol overhead all reduce throughput below that ceiling. So does latency itself: TCP limits how much unacknowledged data can be in flight at once (its receive window), and the maximum sustainable throughput for a single connection is approximately window size divided by round-trip time. This is the bandwidth-delay product — on a high-latency path, a connection can spend most of its time waiting for acknowledgments rather than sending, capping throughput well below the pipe's rated capacity even when bandwidth is generous.
A stuttering video call or delayed-feeling game input is usually a latency problem, and upgrading bandwidth does nothing to fix it, because it doesn't shorten the physical path to the far server. The actual fixes for high latency are a shorter or better-routed network path, a server or CDN edge that's physically closer, or a different protocol — none of which is 'buy more bandwidth.' Conversely, slow large-file downloads on an already low-latency connection often genuinely improve with more bandwidth. Telling the two problems apart is the practically useful skill, since their fixes don't overlap.
Because latency is set by the physical distance a signal has to travel (plus per-hop processing delay), not by how much data the connection can carry at once. A wider pipe moves more data per second once it's flowing, but it doesn't make the signal travel faster or shorten the path to a distant server. The round-trip time to that server stays the same no matter how much bandwidth you buy.
It's the amount of data that can be 'in transit' on a connection at any single instant, equal to bandwidth multiplied by round-trip delay. TCP's receive window limits how much unacknowledged data can be in flight, so on a high-latency path, that window can run out before the pipe's full bandwidth ever gets used — throttling throughput even though the underlying link could theoretically carry much more.
It helps a lot. Modern operating systems support much larger negotiated windows than the historical 64 KB default, and techniques like parallel connections or protocols such as QUIC/HTTP-3 can further improve throughput on long, high-bandwidth paths. None of that changes the round-trip latency itself, though — it only changes how much of the available bandwidth a connection can actually use despite that latency.
Yes, as a first approximation — a ping measures the round-trip time for a small packet, which is dominated by the same propagation and processing delay that affects real application traffic. It won't capture protocol-specific overhead (like a TLS handshake) or bandwidth-delay-product throttling, but it's the right tool for confirming whether a 'laggy' complaint is a latency issue in the first place.
Because the feeling of smoothness in a real-time call is governed far more by round-trip latency (and its variation, jitter) than by bandwidth. A nearby server keeps the round trip short regardless of the plan's bandwidth rating; a distant server has a long, physics-imposed round trip that a bigger bandwidth number cannot shorten. This is exactly why latency-sensitive services rely on geographically distributed servers and CDN edges rather than simply provisioning more bandwidth.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.