Latency vs Bandwidth vs Throughput: What's the Difference?
Latency is how long data takes to travel; bandwidth is the maximum amount a link can carry per second; throughput is what you actually achieve. A fast connection with high latency can feel slow because many tasks depend on waiting for replies, not on moving bulk data. On long paths, round-trip time and the amount of data in flight together limit throughput.
On this page
- What do latency, bandwidth and throughput each mean?
- The highway analogy, done carefully
- Why can 1 Gbps still feel slow?
- How does round-trip time limit throughput? The bandwidth-delay product
- Speed tests vs latency tests
- Throughput, goodput and overhead
- When does each one matter?
- More worked examples
- Common mistakes and myths
- What to do next
Quick answer: latency is how long it takes data to get somewhere (milliseconds), bandwidth is the maximum amount of data a link can carry per second (megabits or gigabits per second), and throughput is the rate you actually get in practice. They are related but independent: you can add bandwidth without reducing latency, and a very low-latency link can still be slow for large downloads. Which one matters depends on what you are doing: bulk transfers care about throughput, interactive things such as games, calls, remote desktops and the start of web page loads care about latency.
What do latency, bandwidth and throughput each mean?
| Term | Question it answers | Unit | Determined by |
|---|---|---|---|
| Latency | How long does one message take? | ms | Distance, route, queuing, processing |
| Bandwidth | How much can the link carry per second at most? | Mbps, Gbps | Link technology and plan |
| Throughput | How much did we actually move per second? | Mbps, MB/s | Slowest link, latency, loss, protocol, endpoints |
| Goodput | How much useful data per second reached the application? | Mbps, MB/s | Throughput minus overhead and retransmissions |
A note on units: network speeds are quoted in bits per second (Mbps), file sizes in bytes (MB). One byte is 8 bits, so a 100 Mbps link tops out at 12.5 MB/s. Forgetting this factor of eight causes constant confusion.
The highway analogy, done carefully
Imagine a road between two cities. The length of the road and the speed limit decide how long one car takes to make the trip: that is latency. The number of lanes decides how many cars can travel side by side: that is bandwidth. The number of cars that actually arrive per hour is throughput, which depends on traffic jams, accidents (packet loss), and how many cars the origin dispatches (the sender's rate).
The analogy is useful for several reasons:
- Adding lanes does not shorten the trip for one car. More bandwidth does not reduce latency.
- A very short road with one lane carries few cars but each arrives quickly: low latency, low bandwidth.
- A very long, wide road moves many cars per hour but each takes a long time: high latency, high bandwidth. Satellite links are like this.
Where the analogy misleads: real packets are not independent cars. Many protocols, notably TCP, send a limited number of cars and then wait for a "delivered" message before sending more. On a long road the waiting dominates, which leads to the bandwidth-delay product below.
The pipe analogy
Another common picture is water in a pipe: bandwidth is the pipe's diameter, latency is how long a drop takes to travel its length. A wide pipe does not make a drop arrive sooner. A long pipe takes a long time to start delivering water, but once it is full it delivers at full rate. Again this fits bulk transfers well; for tiny messages the start-up time is everything.
Why can 1 Gbps still feel slow?
A gigabit plan is a statement about maximum capacity of the connection to your provider. Many things sit between that and a good experience:
- Distance to the server. If the site is on another continent, every handshake takes 100 to 250 ms regardless of plan.
- Many small requests. A page can need dozens of files. Each uses a few round trips, and most of the time is waiting, not transferring.
- The server's own speed. A slow database query or an overloaded server limits you at any bandwidth.
- Wi-Fi. A distant or congested wireless link can deliver a fraction of the plan's rate and add variable delay.
- Queuing on your own line. When uploading or downloading saturates the link, packets queue and latency for everything else rises. See bufferbloat.
- Single-connection limits. One TCP connection over a long path may not use all the bandwidth, as the next section shows.
Practical consequence: upgrading from 100 Mbps to 1 Gbps makes a large file download from a nearby fast server up to roughly ten times quicker, but loading a typical web page changes little, and a game's ping is unchanged.
How does round-trip time limit throughput? The bandwidth-delay product
The bandwidth-delay product (BDP) is the bandwidth multiplied by the round-trip time. It is the amount of data "in flight" needed to keep the path full.
BDP = bandwidth (bits/s) × RTT (s)
| Path | Bandwidth | RTT | BDP |
|---|---|---|---|
| Home LAN | 1 Gbps | 1 ms | 125 kB |
| Same country | 1 Gbps | 20 ms | 2.5 MB |
| Transatlantic | 1 Gbps | 80 ms | 10 MB |
| Intercontinental | 1 Gbps | 200 ms | 25 MB |
| Geostationary satellite | 100 Mbps | 600 ms | 7.5 MB |
TCP, the protocol behind most web traffic, only allows a certain amount of unacknowledged data to be outstanding, controlled by a window. The maximum throughput of a single connection is approximately:
throughput ≤ window size ÷ RTT
Worked example
Suppose a connection can have at most 64 KB in flight (the classic limit without window scaling; modern systems normally scale beyond this). With a 20 ms RTT:
- 64 KB = 524,288 bits; ÷ 0.020 s ≈ 26 Mbps.
- With the same window at 200 ms RTT: 524,288 ÷ 0.2 ≈ 2.6 Mbps.
Ten times the delay, one tenth of the throughput, on a link that could carry a gigabit. Modern operating systems use window scaling and auto-tuning so windows can grow to many megabytes, but the window still has to grow, and that takes round trips (see TCP and UDP explained for slow start). It is also why downloads from far away often ramp up slowly and why running several parallel connections can fill a path that one connection cannot.
Speed tests vs latency tests
A typical speed test connects you to a test server chosen to be close, opens several parallel connections to make full use of the path, and reports download Mbps, upload Mbps and a latency figure. That is a valid and useful measurement of the best-case capacity of your connection to a nearby server. It does not tell you:
- how a server far away will respond,
- how stable latency is over time,
- how a specific game, website or company server performs from your location.
A latency test sends small requests and times how long replies take; it uses almost no bandwidth. GlobeLatency is a latency test: it times real HTTPS requests from your browser to many destinations worldwide and compares each with the world average for that destination. It is not a speed test and does not report Mbps. The two types of test are complementary: use a speed test to check capacity, and a latency test to check responsiveness and reach.
Throughput, goodput and overhead
Every packet carries headers: Ethernet, IP, TCP or UDP, and often TLS framing. For a typical full-size TCP packet over IPv4 on Ethernet, about 1,460 bytes of payload ride in a 1,500-byte IP packet, plus Ethernet framing, so overhead is a few percent. Retransmitted packets and encryption overhead lower goodput further. The practical rule of thumb is that on a healthy wired link a single TCP download can reach roughly 90 to 95 percent of the nominal bandwidth, and noticeably less on Wi-Fi or lossy paths.
When does each one matter?
| Activity | Cares most about | Why |
|---|---|---|
| Downloading a large game or file | Throughput, bandwidth | Bulk transfer; delay is negligible against total time |
| Online gaming | Latency, jitter, loss | Small packets, many per second; bandwidth use is low |
| Video call | Latency, jitter, loss, modest upload bandwidth | Real-time, a few Mbps per stream |
| 4K streaming | Sustained throughput (roughly 15 to 25 Mbps for a stream) | Buffering hides latency |
| Browsing | Latency first, then bandwidth for heavy pages | Many sequential round trips |
| Remote desktop, SSH | Latency | Each key press waits for a reply |
| Cloud backup | Upload throughput | Long bulk transfers |
More worked examples
Example 1: Download time vs latency
A 500 MB file over a clean 200 Mbps path takes about 500 × 8 ÷ 200 = 20 seconds. Adding 100 ms of latency changes the time by a fraction of a second (a few round trips of ramp-up) but a bandwidth cut to 100 Mbps doubles it. For bulk transfers, bandwidth dominates.
Example 2: Loading a page
A page needs 40 small files, delivered over 6 parallel connections. Roughly 7 sequential rounds of requests, each costing one RTT plus server time, plus the connection setup. At 20 ms RTT that is about 7 × 20 = 140 ms of waiting for round trips; at 200 ms RTT, about 1,400 ms. The total bytes could be only 2 MB, which a 100 Mbps link moves in 0.16 s. Latency decides the outcome.
Example 3: Ping with a saturated upload
Your RTT to a server is 15 ms when idle. You start a large cloud upload, which fills the 20 Mbps uplink, and RTT climbs to 300 ms because packets queue in the router buffer. Bandwidth was fully used, and latency suffered. Throughput was fine; responsiveness was not.
Common mistakes and myths
- "Faster plan, lower ping." Only if congestion was the cause.
- Mixing up Mbps and MB/s. 100 Mbps is 12.5 MB/s.
- Treating a speed test as proof the line is fine. It tests a nearby server, usually with parallel connections.
- Assuming the ISP promises the number. "Up to" speeds are maximums; delivered throughput depends on everything on the path.
- Ignoring upload. Calls and cloud games depend on upload capacity and on latency while uploading.
- Thinking latency and throughput can be traded in one number. They are different dimensions and need different fixes.
What to do next
Measure the delay side with the free latency test and the capacity side with any speed test, then compare. Read what is latency for the components of delay, what is a good latency to judge your numbers, and bufferbloat if your latency rises when the line is busy. To improve responsiveness, see how to reduce latency.
Frequently asked questions
What is the difference between latency and bandwidth?
Latency is the time a single piece of data takes to travel, measured in milliseconds. Bandwidth is the maximum rate at which data can be sent over a link, measured in megabits or gigabits per second. Latency is about delay; bandwidth is about capacity. A link can have high bandwidth and high latency, such as a satellite connection, or low bandwidth and low latency.
Why is my internet slow when I have gigabit speed?
Common reasons are high latency to the server you are using, Wi-Fi limitations, a slow or overloaded server, congestion elsewhere on the path, or queuing on your own line (bufferbloat). Most web activity is many small request and response exchanges, so it is limited by round trips and server speed, not by your line's maximum rate.
Is throughput the same as bandwidth?
No. Bandwidth is the theoretical maximum capacity of a link. Throughput is the rate actually achieved by a transfer, which is usually lower because of protocol overhead, latency, packet loss, congestion and the limits of both endpoints. Throughput can never exceed the bandwidth of the slowest link on the path.
What is the bandwidth-delay product?
It is bandwidth multiplied by round-trip time, and it equals the amount of data that must be in flight to keep a link fully used. A 1 Gbps path with 100 ms RTT has a bandwidth-delay product of 12.5 MB. If a sender can only have less than that outstanding unacknowledged, it cannot fill the link.
Does a speed test measure latency?
Most speed tests report latency (often called ping) as a separate number, taken before or during the transfer test. The headline download and upload figures measure throughput towards a specific nearby test server, which is usually the best case. They do not show how a distant or busy destination will perform.
What is goodput?
Goodput is the rate of useful application data delivered, excluding protocol headers, retransmitted data and other overhead. It is always lower than raw throughput on the wire. If you download a 100 MB file in 10 seconds, your goodput is about 80 Mbps even though the link carried somewhat more bits than that.