The question this whole rung answers
You have already built the entire web stack from the ground up. You know a TCP connection opens with the round-trip dance of the three-way handshake, that HTTP requests a page and the server replies, that names turn into addresses through the Internet's phone book. So here is a fair question: why, after all that beautiful machinery, does clicking a link sometimes feel like waiting for a kettle to boil? This rung is the answer. Over five guides we will see exactly where the time goes when the web feels slow, and the clever tricks — caching, proxies, content delivery networks, load balancing, adaptive streaming — that engineers use to claw it back.
The first step, and the most important idea in the entire rung, is to stop blaming the wrong thing. When a page loads slowly almost everyone's first instinct is the same: my connection is too slow, I need more bandwidth. Sometimes that is true. But astonishingly often it is not — and chasing more bandwidth when the real culprit is distance is like buying a wider driveway to shorten a long road trip. To see why, we have to pull apart three words that get muddled together every day: bandwidth, throughput, and latency.
Bandwidth, throughput, latency: three different things
Think of a pipe carrying water. Bandwidth is how wide the pipe is — the maximum bits per second the link could carry if it were running flat out, say 100 Mbps or 1 Gbps. Throughput is how much water is actually flowing right now, which is always less than the width because of overhead, sharing, and congestion. A path made of several links is only as fast as its narrowest one, so end-to-end throughput is min(R1, R2, ...) — the bottleneck wins, exactly as you saw earlier in the ladder. Crucially, both of these measure volume per second: how MUCH you can move.
Latency is a completely different quantity: it is the delay — how LONG it takes a single bit to travel from one end to the other. A wide pipe does nothing to shorten the pipe. You can pour water in faster, but the first drop still has to travel the whole length before it arrives. This is why the headline honesty of this subject is worth saying plainly: more bandwidth does NOT cut latency. Upgrading from 100 Mbps to 1 Gbps lets you download a huge file in a tenth of the time, but it does not make a small request come back any sooner if the server is on another continent. You cannot beat the speed of light by buying a fatter pipe.
Where latency comes from — and the part you cannot fix
Recall the breakdown of delay from early in the ladder. The total time a packet spends getting somewhere is the sum of four parts: the transmission delay (time to push the bits onto the wire, which depends on bandwidth), the processing delay (a router glancing at the header), the queuing delay (waiting in line behind other packets), and the propagation delay (the bits physically travelling the distance at nearly the speed of light). The first three you can attack with faster hardware, smarter queues, and fatter links. The fourth one you cannot. It is set by physics and the distance, and it is usually the part nobody can engineer away.
Let us make it concrete. Light in a vacuum covers about 300,000 km in one second; in glass fibre it is slower, roughly 200,000 km per second. London to Sydney is about 17,000 km in a straight line — but fibre does not run straight, it follows coastlines and cable routes, so call it 20,000 km of glass. That is 20,000 / 200,000 of a second, about 100 ms, just to go ONE way, in a perfect world with zero queuing and instant routers. A round trip — there and back — is already 200 ms, and that is the absolute floor that no upgrade, no money, no clever code can go below. It is the cost of the planet being round and large.
one-way propagation, London <-> Sydney (fibre, ~20,000 km)
-----------------------------------------------------------
distance / speed-in-fibre = 20,000 km / 200,000 km/s
= 0.1 s = 100 ms one way
= 200 ms round trip (the hard floor)
...and a fresh HTTPS page often needs SEVERAL round trips:
DNS lookup ~1 RTT (find the address)
TCP handshake ~1 RTT (SYN, SYN-ACK, ACK)
TLS handshake 1-2 RTT (agree on encryption)
HTTP request ~1 RTT (finally ask for the page)
----------------------------------------------------------
~4 RTT x 200 ms ~= 0.8 s before a single useful byte arrives
The round-trip tax: why one click is many trips
Here is the part that surprises people most. A single page load is almost never one trip across the ocean — it is a stack of them, and many must happen in order, each waiting for the last to finish. As the sketch above shows, before a brand-new encrypted page can even start arriving, the browser may pay a round trip to look up the name in DNS, another to complete the TCP handshake, one or two more to agree on encryption with TLS, and only THEN one to send the actual HTTP request. Each of those is taxed the full round-trip time. When that time is 200 ms, four sequential trips burn most of a second before a single useful byte lands.
It gets worse, because a modern web page is not one file. It is an HTML document that, once parsed, asks for dozens or hundreds more things — stylesheets, scripts, fonts, images — each potentially its own request. If the browser fetched them strictly one after another, every fetch would pay the round-trip tax again, and the page would crawl. This is exactly why so much web-performance engineering is really latency engineering: reusing one connection for many files (a persistent connection), letting many requests fly in parallel without waiting for each reply, and shaving off whole round trips wherever possible. Protocols like HTTP/2 and QUIC exist largely to fight this round-trip tax — QUIC even folds the connection and encryption setup together so a returning visitor can start sending data in zero extra round trips.
The one lever that actually works: shorten the distance
If the round-trip floor is set by distance, and a page needs several round trips, then the single most powerful thing you can do is the obvious one: make the distance shorter. You cannot move Sydney closer to London — but you can put a COPY of the content in Sydney, so the user there talks to a nearby machine instead of one across the ocean. A 5 ms round trip to a server in the same city, multiplied across four handshakes, is a fraction of a fraction of that 800 ms. The physics did not change; the distance did.
- Imagine one origin server in London holding the real website, serving the whole planet directly.
- Every visitor — Sydney, Tokyo, São Paulo — pays the full long-distance round trip, several times over, for every page.
- Now scatter dozens of edge copies around the world, each near a cluster of users, holding the same content.
- Steer each visitor to the nearest copy, so their round trips are tens of kilometres instead of tens of thousands.
- The same bits travel a tiny distance, every stacked round trip shrinks, and the web suddenly feels fast.
That network of scattered copies is a content delivery network, or CDN — think of it as a chain of local warehouses for the web. Instead of everyone ordering from one distant factory, the goods are pre-stocked in a warehouse near you, so delivery is a short hop rather than an intercontinental haul. The rest of this rung builds that idea up properly: the next guide explains how a copy knows whether it is still fresh (HTTP caching, ETags, the 304), then how CDNs and their edge servers are organised, how a request is steered to the right nearby copy (DNS tricks and anycast) and balanced across machines, and finally how even live and on-demand video lean on the same distance-shrinking idea with adaptive streaming. Everything ahead is, at heart, a war on the round trip.