Latency vs bandwidth

Two ways a connection can be slow

Ravi pays for a faster internet plan. His old plan carried 20 megabits every second. A megabit is a million bits, the 0s and 1s that all data is made of. The new plan carries 100 megabits, five times as much. That evening he opens the tea of the week page at Leaf and Kettle, the tea shop from the first lessons. He expects the tea's picture to pop up five times sooner. It doesn't. It shows up at almost the same moment as before.

What did the faster plan buy him? The course loaded the same page in Chrome 156 on both connections, and wrote down when the picture appeared:

1// The tea of the week page, loaded twice in Chrome.2// Both times, a message took 150 ms to reach the server and come back.3const on20Mbps = { lcpMs: 704 };4const on100Mbps = { lcpMs: 676 };5 6console.log(`On 20 Mbps, the tea's picture appeared at ${on20Mbps.lcpMs} ms.`);7console.log(`On 100 Mbps, it appeared at ${on100Mbps.lcpMs} ms.`);8console.log(`Five times the bandwidth saved ${on20Mbps.lcpMs - on100Mbps.lcpMs} ms.`);

• Lines 1 and 2 are comments. They say what was measured: the same page, twice, with every message taking 150 ms to reach the server and come back.
• Lines 3 and 4 hold the two recorded times. LCP, Largest Contentful Paint, is the moment the biggest thing on the screen appears. On this page, that's the tea's picture. It's counted in milliseconds (ms) from the start of the visit.
• Lines 6 and 7 print them: On 20 Mbps, the tea's picture appeared at 704 ms. and On 100 Mbps, it appeared at 676 ms.
• Line 8 subtracts one from the other. It prints Five times the bandwidth saved 28 ms.

A saving of 28 ms is far too small for anyone to notice. So where did the rest of the 676 ms go? Here is the 20 Mbps load, one bar per request. Each bar starts when the browser asks for a file, and ends when the file has arrived:

The page made four requests, one after another:

1. the page itself, the HTML;
2. app.js, the script the HTML names;
3. teas.json, the list of teas the script asks for;
4. the tea's picture, whose name is written in teas.json.

Each request had to wait for the one before. The browser can't ask for the picture until it knows the picture's name. It only learns that name from teas.json.

Now look at how long the bars are. The files are small. Three of them are under 1 KB, a kilobyte, which is a thousand bytes. The picture is about 100 KB. At 20 Mbps, even the picture downloads in about 40 ms. So most of each bar isn't downloading. It's waiting: the request travelling to the server, and the reply travelling back.

A message there and its reply back is called a round trip. This page needs four of them in a row. At 150 ms each, that's 600 ms of waiting, on any plan.

That's the answer to Ravi's puzzle. A connection has two different speeds, and his plan only sold him one of them:

• Bandwidth is how much data the line can carry each second. It's counted in megabits per second, or Mbps. Bandwidth is the number on the plan.
• Latency is how long one message takes to get from one end to the other. It's counted in milliseconds.
• The round-trip time, or RTT, is how long a request takes to reach the server, plus its reply to come back.

Here are the three words side by side. Read each row across, and compare the last column with the road:

Round-trip time and the speed of light

Ravi's round trip took 150 ms. His messages were tiny, so why did each one take that long? And could a better connection bring it down to 1 ms?

Start with what one round trip is. The request travels to the server, the server answers, and the reply travels back:

On the way, a message doesn't travel in one piece. Data crosses the internet in small pieces called packets. Each packet passes through many routers. A router is a computer that reads a packet's address and sends it on toward the server.

Ilya Grigorik's book High Performance Browser Networking splits the time a packet takes into four parts. They're easiest to picture as a parcel going through the post:

In network words, the four parts are:

• Propagation: the time the signal takes to cross the distance.
• Transmission: the time it takes to put the packet's bits onto the wire. A faster link does it sooner.
• Processing: the time each router takes to read the packet's address and choose where to send it next.
• Queuing: the time a packet waits at a busy router, behind other packets.

Better equipment can shrink the last three. Propagation is different. It depends only on the distance and on how fast the signal travels. And nothing travels faster than light.

Light covers about 300,000 km a second in empty space. Long-distance internet cables are made of glass fiber, and light is slower in glass: about 200,000 km a second. That's 200 km every millisecond. So how fast could a message cross the Atlantic and come back?

1// Light in glass fiber covers about 200 km every millisecond.2const fiberKmPerMs = 200;3const route = { from: "New York", to: "London", km: 5585 };4 5const roundTripMs = (2 * route.km) / fiberKmPerMs;6console.log(`${route.from} to ${route.to} and back: at least ${Math.round(roundTripMs)} ms`);

• Line 2 is the speed of light in fiber: 200 km every millisecond.
• Line 3 is the route: New York to London, 5,585 km.
• Line 5 doubles the distance, because a round trip goes there and back. Then it divides by the speed: 11,170 km at 200 km every millisecond.
• Line 6 rounds the result and prints New York to London and back: at least 56 ms.

It says "at least" because this is light in a perfectly straight cable, with no routers on the way. Grigorik's book does the same sum for three routes. Each row is one route, how far it is, and how fast light in fiber could cover it:

Real messages are slower than the table. Cables don't run in a straight line between cities. And every router on the way adds processing and queuing. Grigorik puts the real round trip from New York to Sydney at 200 to 300 ms.

Often the slowest part isn't the ocean at all. It's the last few miles: the link from a home or a phone to its provider's network. Those first few hops alone can take tens of milliseconds.

Why does this matter? No amount of bandwidth shortens a round trip. Only a shorter distance does. That's why sites use a CDN, a content delivery network: copies of the site's files on servers all over the world. It works like a tea shop with a branch in every town, so nobody has to travel far. CDNs and the edge covers them later in the course.

How long is your own round trip to this site? Press Measure to find out. The panel asks for a tiny file ten times, and times each reply:

1for (let i = 0; i < 10; i++) {2  await fetch(`${url}?n=${i}`, { cache: "no-store" });3}4 5const times = performance.getEntriesByType("resource")6  .filter((entry) => entry.name.includes(url))7  .map((entry) => entry.responseStart - entry.requestStart);8 9const roundTrip = Math.min(...times);10const estimate = navigator.connection?.rtt;

The panel uses Resource Timing. For every file a page fetches, the browser writes down when it sent the request and when the first byte of the reply arrived. It's like a stopwatch the browser clicks twice for each file. In the panel's code:

• Line 7 subtracts those two times for each request: from sending it (requestStart) to the first byte of the reply (responseStart).
• Line 9 keeps the fastest one. Each time includes the server's own work and any queuing on the way. The fastest request had the least of both, so it's the closest to the pure round trip.
• Line 10 reads the browser's own guess, navigator.connection.rtt. Chrome and Edge give it. Firefox and Safari don't.

Why more bandwidth stops helping

Back to Ravi. His plan got five times faster, and his page got 28 ms faster. Why does more bandwidth stop helping? A kitchen makes it easy to see:

A page load works the same way. It has two parts: waiting for replies, and downloading the bytes. Here is one load as a simple sum, with round numbers:

1// One load of a page, as a simple sum.2// The page: 4 requests in a row, and 100 KB to download.3// The line: 150 ms there and back, and 5 megabits per second.4const waitingMs = 4 * 150;5const downloadMs = (100 * 8) / 5;6 7console.log(`Waiting for replies: ${waitingMs} ms`);8console.log(`Downloading the bytes: ${downloadMs} ms`);

• Lines 1 to 3 describe the page and the line. The page needs 4 requests in a row and 100 KB of files. The line has a 150 ms round trip and carries 5 Mbps.
• Line 4 is the waiting: 4 round trips of 150 ms each.
• Line 5 is the downloading. A byte is 8 bits, so 100 KB is 800 kilobits. A line of 5 megabits per second carries 5 kilobits every millisecond. So 800 kilobits take 800 ÷ 5 = 160 ms.
• Lines 7 and 8 print Waiting for replies: 600 ms and Downloading the bytes: 160 ms.

Now try two upgrades, one at a time. Which one helps more?

1// The same sum, with one upgrade at a time.2const waitingMs = 600; // 4 round trips of 150 ms3const downloadMs = 160; // 100 KB at 5 Mbps4 5console.log(`As it is: ${waitingMs + downloadMs} ms`);6console.log(`Double the bandwidth: ${waitingMs + downloadMs / 2} ms`);7console.log(`Halve the round trip: ${waitingMs / 2 + downloadMs} ms`);

• Lines 2 and 3 are the two parts from the last example: 600 ms of waiting, and 160 ms of downloading.
• Line 5 adds them up. It prints As it is: 760 ms.
• Line 6 doubles the bandwidth, which halves only the downloading. It prints Double the bandwidth: 680 ms.
• Line 7 halves the round trip, which halves only the waiting. It prints Halve the round trip: 460 ms.

Doubling the bandwidth saved 80 ms. Halving the round trip saved 300 ms. Bandwidth can only shrink the downloading part. The round trip shrinks the waiting part, and this page waits four times. It's the kettle again: a stronger tap only speeds up the filling, never the walks.

That's a sum on paper. Does a real browser agree? The course loaded the tea page in Chrome 156 under seven different networks. For each load, the recorder:

• added exactly one round trip to every request;
• capped the download speed at the bandwidth in the table;
• left the computer's processor at full speed, so only the network changed.

Each row below is one load. Read it across: the round trip, the bandwidth, when the picture appeared (LCP), and how long four round trips take on that network:

Here are the same seven loads as bars. On the left, only the bandwidth changes. On the right, only the round trip changes:

Three things stand out:

• Each step up in bandwidth helped less than the one before. Going from 1.6 to 5 Mbps saved 364 ms. Going from 5 to 20 Mbps saved 132 ms. Going from 20 to 100 Mbps, five times the bandwidth, saved just 28 ms.
• At 100 Mbps, almost all the time was waiting. The four round trips took 600 ms of the 676 ms before the picture appeared. That's 89%, and bandwidth can't touch it.
• Every cut to the round trip kept helping. From 150 ms down to 20 ms, the picture went from 704 ms to 172 ms. Each millisecond cut saved about 4 ms, once for each request in the chain.

Bandwidth does matter while the bytes are the slow part. At 1.6 Mbps, the 100 KB picture alone took about half a second to download. But once the bytes arrive quickly, only the round trips are left.

It isn't only this one small page, either. Mike Belshe helped create SPDY, the protocol that became HTTP/2. He loaded popular sites again and again, raising the bandwidth step by step from 1 to 10 Mbps. Then he did the same while cutting the latency. Grigorik's book describes what he found:

• Going from 1 to 2 Mbps nearly halved the load times.
• Past 5 Mbps, each step gained only a few percent. Going from 5 to 10 Mbps made pages just 5% faster.
• Every 20 ms cut from the latency made pages faster by about the same amount, step after step.

So before you pay for a fix, ask which part is bigger. A page with big files needs bandwidth. A page with many small files in a row needs fewer round trips, or shorter ones. Turn the dials yourself, and watch how the split changes:

How did the recorder slow the network down? Chrome's DevTools protocol is the set of commands DevTools uses to control the browser. One of them slows a page's network on purpose. The recorder used it to set a minimum wait between sending each request and receiving its reply's headers, and a top download speed.

Real connections also spend round trips setting up, and then speeding up. The next lessons cover those. So real pages pay even more round trips than these loads.

Mobile networks and radio wake-up

Asha is on the bus again, the way she was in the first lesson. Her phone has sat in her pocket for a few minutes. She opens the tea page. Before the first request can even leave, her phone has a job to do: it has to wake up its radio.

A phone's radio is the part that talks to the mobile network. It uses a lot of power while it's awake. So when nothing is being sent, it goes to sleep.

To send again, the radio has to ask the nearest tower for a slot to send in, and wait for the answer. That can take several messages back and forth. The part of the network that hands out the slots is the Radio Resource Controller, or RRC. It decides which phone talks when.

How long the wake-up takes depends on the network. Each row is one kind of network, and how long waking from sleep can take:

After sending, the radio doesn't fall asleep at once. It stays fully awake until a timer runs out. Then it steps down into a lighter sleep. Waking from a lighter sleep is quicker, under 50 ms on 4G, but it still isn't free.

Two things follow from this:

• The first request after a pause pays for the wake-up, on top of its round trip.
• Small requests every minute or so keep waking the radio and holding it awake, which drains the battery.

Grigorik cites a study by AT&T Labs of a music app. The app sent a small analytics ping once a minute. Those pings were 0.2% of the bytes it sent and received, but 46% of its battery use. That's the shop that never gets to close.

Why does it matter for your pages? Send small requests together, in one batch, rather than one at a time. And avoid asking the server for news on a timer when you can.

Counting round trips in a page load

By now you know that each round trip costs time, and that bandwidth can't remove it. So the useful question is: how many round trips does a page need? You can count them before you measure anything.

Round trips add up fastest when each request has to wait for the one before. It's like a treasure hunt:

The tea page's hunt has four clues: the HTML, app.js, teas.json and the picture. That's the staircase of bars at the top of the lesson. But a first visit has more round trips, before the first clue. The browser has never talked to this server, so it has to set up a connection first:

1// A first visit to a new HTTPS site: three steps before the first request.2const setup = [3  { step: "DNS lookup: find the server's address", roundTrips: 1 },4  { step: "TCP connection: open a line to it", roundTrips: 1 },5  { step: "TLS 1.3 handshake: agree on a secret code", roundTrips: 1 },6];7 8const setupTrips = setup.reduce((sum, item) => sum + item.roundTrips, 0);9console.log(`Setting up costs ${setupTrips} round trips.`);

• Line 3 is the DNS lookup. The browser turns the site's name into the server's address, the way you look up a shop's phone number.
• Line 4 is the TCP connection. The browser and the server greet each other before any page data flows, like dialling and hearing "Hello?".
• Line 5 is the TLS handshake. The two agree on a secret code, so nobody in between can read the page. That's the S in HTTPS.
• Line 8 adds up their round trips. Line 9 prints Setting up costs 3 round trips.

Each step waits for a reply before the next can start. The next three lessons take one step each: DNS lookups, TCP connections and slow start and TLS without the wait.

Now put the setup and the four clues together, and multiply by the round trip:

1// A first visit to the tea page: set up, then four requests in a row.2const setupTrips = 3; // DNS, TCP and a TLS 1.3 handshake3const chainTrips = 4; // the HTML, app.js, teas.json, the picture4const roundTrips = setupTrips + chainTrips;5 6for (const roundTripMs of [20, 100, 150]) {7  console.log(`${roundTrips} round trips at ${roundTripMs} ms: ${roundTrips * roundTripMs} ms`);8}

• Line 2 is the setup: 3 round trips. Line 3 is the four requests in a row.
• Line 4 adds them up: 7 round trips.
• Lines 6 to 8 repeat the sum for three round-trip times: 20, 100 and 150 ms.
• It prints 7 round trips at 20 ms: 140 ms, 7 round trips at 100 ms: 700 ms and 7 round trips at 150 ms: 1050 ms.

At 150 ms, a first visit spends more than a second just waiting for replies. That's before a single megabit makes any difference. And on a phone, the radio's wake-up comes on top.

Here is what adds round trips to a page:

• New hosts. A host is a server's name, like completefrontend.com. Each new one needs its own lookup and connection. So a font or a script from another site can cost three round trips before its request even leaves.
• Redirects. A redirect is the server answering "this page has moved". The browser has to ask again at the new address, so each redirect costs at least one more round trip. Redirects covers them.
• Chains. Any file that's only found once another has arrived: a stylesheet that imports another, a font named inside the CSS, or data that a script asks for.
• Big files. A new connection starts by sending a little, then speeds up over several round trips. So a large file takes more than one round trip to arrive.

And here is what removes them:

• reusing a connection that is already open;
• connecting early to hosts the page will need;
• cutting redirects;
• naming important files in the HTML, so the browser finds them sooner;
• caching files, so there's nothing to fetch;
• serving files from closer by, with a CDN.

The system design lesson From URL to pixels follows a page from the address bar to the screen in one go. This module takes it one step at a time, starting with these round trips.

Latency numbers to remember

A few numbers are worth knowing by heart. With them, you can guess a page's waiting time before you measure it. Each row is a fact from this lesson or an earlier one, and the sources at the bottom of the page say where it comes from:

Two rows come from earlier lessons. The point where people notice lag is from 0.1 seconds, 1 second, 10 seconds. The 75th percentile is from Averages lie: reading distributions. Here it means that a quarter of users have a slower connection than the one in the table.

Here is the habit to take away. When a page feels slow, don't start with bandwidth. Count the round trips the page waits for in a row. Then multiply them by a realistic round trip. For your slower users, that's 100 ms or more.

Latency or bandwidth?

Each task below is held back mostly by one of the two speeds. For each one, ask: is the time going into waiting for replies, or into moving lots of bytes? Then sort it:

Common mix-ups

• "A faster plan makes websites load faster." No, not past a few megabits. After that, most pages wait on round trips, not bytes. Ravi's plan got five times faster, and his page got just 28 ms faster.
• "Latency means the server is slow." No. Latency is travel time. A slow server adds to the wait, but even an instant server is still a round trip away.
• "My ping time is my page load time." No. A ping measures one round trip. A page needs several in a row, plus time to download and draw.
• "Light is too fast to matter." No, not across oceans. New York to Sydney and back takes 160 ms at best, and every round trip pays it again.
• "Small files are free." No. When each one waits for another, four tiny files cost four round trips.
• "5G removes latency." No. It shortens the radio's part. The distance to the server, and the number of round trips a page needs, stay the same.

Practice exercises

Answer first, then use the hints.

// The same sum, with one upgrade at a time.
const waitingMs = 600; // 4 round trips of 150 ms
const downloadMs = 1600; // 1,000 KB at 5 Mbps

console.log(`As it is: ${waitingMs + downloadMs} ms`);
console.log(`Double the bandwidth: ${waitingMs + downloadMs / 2} ms`);
console.log(`Halve the round trip: ${waitingMs / 2 + downloadMs} ms`);

// Light in glass fiber covers about 200 km every millisecond.
const fiberKmPerMs = 200;
const route = { from: "New York", to: "San Francisco", km: 4148 };

const roundTripMs = (2 * route.km) / fiberKmPerMs;
console.log(`${route.from} to ${route.to} and back: at least ${Math.round(roundTripMs)} ms`);

// The same first visit, to a server that only speaks TLS 1.2.
const setupTrips = 4; // DNS, TCP and a TLS 1.2 handshake, which takes two
const chainTrips = 4; // the HTML, app.js, teas.json, the picture
const roundTrips = setupTrips + chainTrips;

for (const roundTripMs of [20, 100, 150]) {
  console.log(`${roundTrips} round trips at ${roundTripMs} ms: ${roundTrips * roundTripMs} ms`);
}

Check your understanding

For each question, ask: is the time going into waiting for a reply, or into moving bytes?

Key takeaways

• Bandwidth is how much can flow at once. Latency is how long one message takes to arrive. The round-trip time is there and back.
• Light in fiber covers 200 km every millisecond, so distance sets a floor under every round trip. Only a shorter distance lowers it.
• A load is waiting plus downloading. Bandwidth only shrinks the downloading, so past a few megabits it barely helps a typical page.
• Every millisecond cut from the round trip counts once for each request in the chain.
• An idle phone wakes its radio first: under 100 ms on 4G, and up to 2 seconds on 3G.
• Count the round trips a page waits for in a row: setting up, redirects, and each request that needs another. Then multiply by the round-trip time.

Sources

The facts on this page come from these docs and books:

• Primer on Latency and Bandwidth, High Performance Browser Networking, Ilya Grigorik.
• PerformanceResourceTiming, MDN.
• NetworkInformation: rtt, MDN.
• Primer on Web Performance, High Performance Browser Networking (Mike Belshe's study), Ilya Grigorik.
• Network.emulateNetworkConditions, Chrome DevTools Protocol.
• Mobile Networks, High Performance Browser Networking, Ilya Grigorik.
• Minimum requirements related to technical performance for IMT-2020 radio interface(s), Report ITU-R M.2410, ITU.
• The Performance Inequality Gap, 2026, Alex Russell.
• Network throttling, Lighthouse documentation.

Coming next: DNS lookups. Every new host starts with a lookup, the first of the three setup round trips. You'll see what it costs, and how to hide it.