Round Trips Before the First Byte

A new HTTPS connection pays several round trips before any response data arrives: one for TCP, one for TLS 1.3 and one for the request itself, plus one for DNS when the name is not cached. Each round trip costs the full time there and back, so distance multiplies, and no amount of server speed removes it.

Picture an API whose server answers in 5 ms, measured on the server. Users on another continent, 100 ms away, see responses take well over 300 ms, and the team spends a week optimising queries that were never the problem.

The symptom. A fast server and a slow first response, worst for distant users and for clients that open a new connection per request.

Why it happens. Each handshake must finish before the next can start, and each needs a reply from the server. Three round trips at 100 ms is 300 ms before the server's 5 ms even begins. A DNS lookup the resolver must make first adds its own round trips, and TLS 1.2 adds one more, for four in all.

What it costs. Latency that grows with distance and is paid again by every client that does not keep its connection open, or by every serverless function that starts cold.

What saves round trips.

• Reuse. A request on an open connection pays one round trip, not three. Connection pools and keep-alive are the largest saving.
• TLS 1.3. One round trip for the handshake instead of two.
• HTTP/3. QUIC combines the transport and TLS handshakes, so a new connection needs two round trips to the first byte, and a resumed one can send its request in the first packet.
• Distance. A CDN or a regional endpoint puts the handshakes near the user, so each round trip is short.