Latency vs Throughput: What Each One Means for Your Server

Latency vs throughput is the difference between how long data takes to arrive and how much data arrives each second. Latency is a time, measured in milliseconds. Throughput is a rate, measured in megabits per second. A server needs both to feel fast, but a faster port improves only one of them.

This guide defines latency vs throughput, shows how bandwidth fits between them, and explains what RTT means. It then covers what causes high latency and what a dedicated server can and cannot change. The sources are Cloudflare, AWS, web.dev and our own arithmetic.

Latency vs Throughput: What Is the Difference?

Latency is how long one piece of data takes to travel, and throughput is how much data actually arrives per second. Cloudflare</a> puts it plainly: latency measures time, not how much data is downloaded over time. So the latency vs throughput difference is the difference between a duration and a rate.

AWS adds that you can measure latency with ping time. Throughput, by contrast, needs a test that moves data. Also, bandwidth is the third term, and it is the one people mix up most.

Table comparing latency, bandwidth and throughput: latency answers how long it takes and is measured in milliseconds, limited by distance and the path; bandwidth answers how much the path could carry and is measured in Mbps or Gbps, limited by the port and the narrowest link; throughput answers how much really arrives, measured in Mbps or Gbps and limited by bandwidth, latency and congestion; on a 1 Gbps server port, latency depends on where the user is, bandwidth is 1 Gbps and throughput is at most 1 Gbps.

How Does Bandwidth Fit Between Latency and Throughput?

Bandwidth is the ceiling and throughput is what you reach under it. Cloudflare defines bandwidth as the maximum amount of data that can pass at any given time, and throughput as the average amount that actually passes. Throughput is below bandwidth whenever congestion, latency or the endpoints get in the way.

This is why a bigger port does not cure a slow response, and why latency vs throughput is not a question of port size. A faster port raises the ceiling on throughput, but it does not shorten the trip. Our 10 Gbps guide shows how much of an advertised port you really get.

The chart shows the same trip on both ports:

Bar chart comparing a 1 Gbps and a 10 Gbps port: moving 10 GB takes 80 seconds on 1 Gbps and 8 seconds on 10 Gbps, while the minimum round trip from Amsterdam to New York is 58.6 ms on both ports.

Why Does Latency Cap Throughput?

The latency vs throughput link shows up on one TCP connection: the sender waits for acknowledgements, so throughput cannot exceed the window divided by the round-trip time. With a classic 64 KB window, a connection at 10 ms RTT tops out near 52 Mbps, and at 200 ms it tops out near 2.6 Mbps, whatever the port size.

Horizontal bar chart of the throughput ceiling for one TCP connection with a 64 KB window: 52.4 Mbps at 10 ms round-trip time, 10.5 Mbps at 50 ms, 5.2 Mbps at 100 ms and 2.6 Mbps at 200 ms.

However, the real lesson of latency vs throughput is the direction, not the exact number. Longer distance means lower throughput per connection, even on a large port.

What Does RTT Mean?

RTT means round-trip time: the time for a packet to reach a server and for the reply to come back. Cloudflare notes that RTT is double the one-way latency, because data travels there and back. The RTT is the number that ping reports.

However, on a phone, RTT means something else. In calls, it stands for real-time text, an accessibility feature that sends text character by character as it is typed. The FCC’s rules define it that way. It has nothing to do with network delay, so this guide uses RTT only in the networking sense.

What Makes Up Server Latency?

Server latency is the sum of several stages: redirects, DNS lookup, the connection and TLS setup, and the request itself. This is how web.dev breaks down time to first byte. Also, the server’s own processing time comes on top of the network stages.

The connection stages cost whole round trips. Cloudflare counts one round trip for the TCP handshake, two for a TLS 1.2 handshake and one for the HTTP request, which makes four before a page can start. TLS 1.3 needs one round trip instead of two, so a new HTTPS connection needs three.

Our guides to how DNS works and how TCP/IP works explain the first two stages.

Table of the time to first byte on a new HTTPS connection before DNS and server time: at 20 ms round-trip time it is 60 ms with TLS 1.3 and 80 ms with TLS 1.2, at 50 ms it is 150 and 200 ms, at 100 ms it is 300 and 400 ms, and at 200 ms it is 600 and 800 ms.

At 100 ms of RTT, a first request over TLS 1.3 waits 300 ms before the first byte, not because of slow code, but because of three trips. The TLS version is one of the few levers you control.

At 200 ms of RTT over TLS 1.2, the network alone uses 800 ms, the whole 0.8-second budget that web.dev calls a good first byte.

How Does Distance Set the Latency Floor?

Distance sets a hard minimum, because light in fibre travels at roughly two-thirds of its speed in a vacuum, about 200,000 km a second. A round trip to a city 10,000 km away cannot take less than about 100 ms. No server upgrade changes that.

Horizontal bar chart of the minimum round-trip time from Amsterdam over a straight fibre line: 3.6 ms to London, 3.6 ms to Frankfurt, 4.3 ms to Paris, 14.8 ms to Madrid, 58.6 ms to New York and 104.9 ms to Singapore.

Real routes are longer than a straight line, so measured times are higher. What the floor tells you is where a server cannot win. In the latency vs throughput picture, distance hurts both: it adds delay, and it lowers the ceiling per connection. For a mostly European audience, an IXP as dense as AMS-IX, with a 15 Tb/s peak and more than 900 networks connected, keeps the path short. Our how server location affects website speed covers the location choice in full.

What Causes High Latency?

High latency comes from five causes: distance, a poor route, congestion, a busy server and slow processing. A high ping is simply high latency as the ping tool reports it, so the causes of high ping and the causes of high latency are the same list.

Table of five causes of high latency: distance shows as ping rising with the user’s distance and is helped by a closer server or a CDN; a poor route shows as detours or a slow hop in traceroute and is helped by a host with strong peering; congestion shows as times varying between pings and is helped by a different path; a busy server shows as low ping but a slow first byte under load and is helped by dedicated hardware; slow processing shows as low ping and a slow first byte even when idle and is helped by faster storage, queries and code.

How Do You Tell Network Latency From Server Latency?

Compare the ping with the time to first byte. On a new HTTPS connection, the first byte cannot arrive in less than about three pings. If it takes far longer than that, the extra time is inside the server. If the ping itself is high, the delay is in the distance or the path.

In practice, that one comparison saves hours of guessing. A server can have a 5 ms ping and still answer in a second, because the time is spent on a database or a disk. web.dev treats a first byte within 0.8 seconds as good and anything over 1.8 seconds as poor.

Can a Dedicated Server Lower Latency?

A dedicated server lowers the latency that comes from sharing, and lets you choose where it sits, but it cannot beat distance. It gives you the whole machine and the whole port, so no neighbour can queue your requests behind theirs.

Table of what a dedicated server changes and what it cannot: it changes waiting behind another tenant’s load, a port shared with neighbours, the choice of location and network, and the tuning of TLS, storage and software; it cannot change the distance to the user, the user’s own connection, routes beyond your host’s network or the speed of light in fibre.

Swify servers sit in one data centre in the Netherlands, connected to AMS-IX, with a 1 Gbps unmetered port on every plan. As a result, that suits audiences in Europe. None of this changes the latency vs throughput trade-off, but it keeps both steady under load. For users on other continents, the floor above applies, and a CDN does the rest.

Where Does a CDN Stop Helping?

A CDN stops helping at the first request it cannot answer from its cache. Static files come from a nearby edge, but a checkout, a login or an API call goes back to your origin. So the origin’s location and speed still set the latency of those requests.

Our CDN guide covers when the origin still matters.

Which Workloads Feel Latency or Throughput Most?

Games and APIs feel latency most, while backups, downloads and video delivery feel throughput most. Many workloads need both, so the latency vs throughput table shows which one leads.

Table of which measure leads for which workload: latency leads for multiplayer games because every action is a small urgent round trip and for SaaS and APIs because of hundreds of uncached requests per session; throughput leads for live video delivery because each viewer pulls a steady stream and for backups and large transfers because the time depends on how much moves per second.

For SaaS, read Dedicated Server for SaaS. For video, RTMP vs HLS shows how segment length trades delay against load.

How Do You Measure Latency and Throughput?

Measure latency with ping and traceroute, and measure throughput with a test that moves data, such as iperf. Check both from where your users are, because a test run next to the server hides the distance. Latency vs throughput tests answer different questions, so run both.

• Latency: ping reports the RTT, and traceroute shows the hops.
• Throughput: a transfer test shows what you really get, which is often below the port speed.
• First byte: the browser’s timing data shows the effect of both on a real page.

Latency vs Throughput: The Short Version

Latency vs throughput comes down to time against volume: latency is how long a trip takes, and throughput is how much arrives per second. Bandwidth only sets the ceiling, and distance sets a floor that no server can lower.

• Latency is a duration in milliseconds, and throughput is a rate in Mbps.
• A faster port raises the throughput ceiling, but it does not cut latency.
• A dedicated server removes the delay from sharing, not the delay from distance.

Frequently Asked Questions

What is the difference between latency and throughput?

What is the difference between bandwidth and latency?

Is high throughput the same as low latency?

What does RTT mean?

What causes high latency?

Why do I have high latency?

What is a good latency for a server?