A first connection pays for DNS, a TCP handshake, a TLS handshake and then the request itself, and none of them can start until the one before has finished. The time is k·RTT + bytes/bandwidth, and for anything smaller than a few hundred kilobytes the first term is nearly all of it. The useful question is not how many bytes the response is but how many times the conversation went back and forth.
Core ideas
The new idea is the multiplier k. It is a count of sequential exchanges, it is usually between one and six, and it is nearly always the largest thing on the page.
The DNS answer is needed before the TCP connection can open, the connection is needed before the TLS negotiation, and the negotiation before the request. Nothing here overlaps. Four legs at 80 ms is 320 ms of doing nothing but waiting, and the reason it is 320 rather than 80 is ordering, not volume.
The bytes cannot begin to arrive until the last round trip has completed, so k·RTT is not a share of the total — it is the delay before the total starts. On the lab’s preset that is 400 ms of a 411.2 ms request, and the whole payload accounts for the remaining 11.2 ms.
The bytes cost as much as the round trips when bytes/bandwidth = k·RTT, so the crossover payload is k × bandwidth × RTT. At k = 1 that is exactly the bandwidth-delay product of “Latency Is Not Throughput”: the two lessons are one fact, counted once and then k times.
The material
Why the fix for a slow first load is usually removing an exchange rather than removing a kilobyte.
Open the lab at its preset and read the four selectors down the side: a DNS lookup, a TCP handshake, a TLS 1.2 negotiation worth two round trips, and the request itself. That is k = 5, and at an 80 ms round trip the time to first byte is 400 ms. The 14 kB of HTML then costs 11.2 ms at 10 Mbit/s. The whole request takes 411.2 ms, and 97.3% of it is round trips.
The round-trip count k of a request is the number of exchanges that must complete in sequence before the response can begin to arrive. It counts only exchanges on the critical path: work that happens in parallel with something else does not add to k, and that is the whole reason the count is worth taking seriously rather than simply totalling the protocol’s messages.
The ratio is the number that settles the argument. The round trips cost 35.7 times what the payload costs, so a proposal to halve the HTML saves 5.6 ms of a 411.2 ms request — about one and a third percent — while removing a single handshake saves 80 ms, or nineteen percent. Removing one round trip is worth as much as deleting 100 kB on this link, and the HTML is 14 kB.
The two terms are equal when the payload reaches k × bandwidth × RTT, which here is 5 × 100 kB = 500 kB. Below that the round trips dominate and above it the bytes do. A 14 kB document is a thirty-fifth of the way there, which is why the byte count is not the lever; a 4 MB video segment on the same connection is eight times past it, and for that one the bytes are the whole story.
Cache the DNS answer, reuse the connection, and the only exchange left is the request itself: k = 1. Time to first byte falls from 400 ms to 80 ms and the total from 411.2 ms to 91.2 ms — a saving of 320 ms, which is 78% of the original. Nothing about the payload changed, and nothing about the link changed. Four exchanges were removed from the front of the request.
Every entry in that list except the last is overhead that a well-configured client and server pay once and then stop paying. This is the reason a site feels slow on the first page and fast on the second, and it is why the measurement to trust is the cold one.
The misconception this lesson exists to name is optimising the term you are not paying. Shaving bytes when k·RTT is thirty-five times the byte cost is work that will be done carefully, measured honestly, and found to have achieved nothing. Compute the ratio first, and let it choose the work.
Interactive
k × RTT + bytes ÷ bandwidth, with k the part you can change
Method
The count comes first, because it decides whether the byte count matters at all.
DNS, connection, encryption, request. Count only what is sequential: a lookup that happens while another connection is already open does not add to k, and neither does anything the client did before the user clicked.
That product is the time to first byte. It is not a share of the response time; it is the delay before the response time starts, and it is the same whether the answer is one byte or one megabyte.
size × 8 / (Mbit/s × 1000) is the byte cost in milliseconds. Divide the round-trip term by it. A ratio above about three means the payload is not where the time is going.
Each removed round trip is worth exactly RTT milliseconds. Compare that with what a realistic reduction in payload would save, using the crossover payload k × bandwidth × RTT as the point at which the two swap places.
Same page, same link, same bytes. The only thing that changes is how many times the two ends have to talk before the content can start.
The saving is four round trips and not one byte. That is the shape of almost every real first-load improvement, and it is why the protocol versions matter: moving from TLS 1.2 to 1.3 removes one round trip, which on this link is worth fourteen times what halving the document would be worth.
The crossover payload is k × bandwidth × RTT. At k = 5 on this link it is 500 kB; at k = 1 it is 100 kB, which is the bandwidth-delay product from “Latency Is Not Throughput”. Removing handshakes therefore moves the crossover downward as well as moving the total: on a warm connection the payload starts mattering sooner.
For a faded rehearsal, take a mobile connection at 150 ms round trip and 5 Mbit/s, fetching a 40 kB JSON response over a cold TLS 1.3 connection with an uncached DNS entry. The supplied first move is the count: 1 + 1 + 1 + 1 = 4. Compute the time to first byte, the byte term, the total and the ratio, then say what resuming the session would save and what halving the JSON would save. Check both figures in the lab before opening the quiz.
You should be able to count k for a described connection, compute time to first byte and the byte term, express their ratio, and name the crossover payload at which the two swap places.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.