The cost of a cold connection
Every time I look at a latency chart that says "first byte: 1.8s", someone in the room asks why the same page feels instant on their laptop. The honest answer is usually that the laptop is not paying the connection cost: it has a warm socket, a warm TLS session ticket, a warm DNS entry, and a proxy that already knows the way.
So I spent a week measuring the cold path on purpose, with everything cleared between requests: DNS, TCP, TLS, and the first application byte, separated so I could see which stage was actually expensive.
What the stages cost
On a link with ~170 ms round trip, a cold request to a well-behaved HTTPS endpoint looked roughly like this:
DNS lookup 18 ms (cached resolver, warm) TCP handshake 172 ms (one RTT) TLS 1.3 handshake 176 ms (one RTT, no resumption) Request + TTFB 180 ms (one RTT) ------------------------------------------- total ~550 ms
That is the floor, and it is three round trips. Anything above it is either server time, packet loss, or a middlebox that decided your handshake looked suspicious.
Where it goes wrong
Two things dominate once the floor is established. The first is loss: on a path with 2% loss, a single retransmit costs one RTT plus the retransmission timer, which is why the same request can take 550 ms at 2am and 2.4 s at 8pm. TCP does not negotiate; it backs off.
The second is queueing in the middle. A handshake is a handful of small packets, and small packets are the first thing a full buffer eats. The connection then completes, but the first data packet waits behind a standing queue that has nothing to do with your server.
If the handshake is fast and the first byte is slow, the problem is not the handshake. It is the queue you cannot see.
What I do about it
Keep connections warm where it matters, keep the number of round trips honest, and measure the stages separately instead of staring at one total. And when a number moves by a factor of four between two hours of the day, treat that as the signal, not the noise.