awesome-everything RU
↑ Back to the climb

Networking & Protocols

DNS, TCP, TLS in sequence: where the milliseconds go

Crux Seven concrete phases from cold DNS to first encrypted byte, with timing numbers and the optimisation levers (TLS resumption, 0-RTT, connection coalescing) that eliminate round-trips instead of shortening them.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the sky
◷ 14 min

A colleague reports the site “feels slow on first visit.” You pull a Lighthouse trace and see 320 ms before the first byte arrives. Understanding exactly which of DNS, TCP, and TLS ate that time — and which optimisation eliminates round-trips rather than just shortening them — is the difference between shipping a real fix and guessing.

Phase-by-phase timing budget

Assuming a warm CDN-fronted site (London user, London edge PoP, ~25 ms RTT to edge):

PhaseCold (first visit)Warm (repeat visit)Elimination lever
DNS30–100 ms (resolver walk)<1 ms (OS cache)dns-prefetch / long TTL
TCP handshake~25 ms (1 RTT regional)0 ms (connection pooled)connection keep-alive / preconnect
TLS 1.3 new~25 ms (1 RTT)0 ms (0-RTT resumption)session ticket / PSK
HTTP request~25 ms (1 RTT)~25 msCDN edge cache hit
Total to TTFB105–175 ms25–30 ms

The key insight: DNS and TCP are eliminated by caching and connection pooling on repeat visits. TLS is eliminated by session resumption (PSK). On a warm return visit, TTFB can drop from 175 ms to under 30 ms — not because the network got faster but because round-trips were removed entirely.

Phase 1: DNS (~30 ms cold, <1 ms warm)

The browser asks Rex: “What is the IP for example.com?” Rex checks its cache. Cache warm → replies in microseconds. Cache cold → Rex walks the hierarchy: root nameserver → .com TLD nameserver → example.com authoritative nameserver. Each hop is one network round-trip. A cold DNS lookup in North America or Europe takes 30–100 ms.

The TTL trap. If a CDN operator sets TTL=60 s to enable rapid failover, most users pay the cold DNS cost far more often than necessary. TTL=300 s is a better default for most cases — five minutes of resolver caching, still failover in under five minutes.

Optimisation: dns-prefetch. Adding <link rel="dns-prefetch" href="//cdn.example.com"> to your HTML asks the browser to resolve anticipated hostnames during page parse, before the main parser reaches the actual resource URLs. Cost: a few milliseconds of DNS time moved off the critical path.

Phase 2: TCP handshake (1 RTT, 10–100 ms by geography)

Bea sends SYN → Sven responds SYN-ACK → Bea sends ACK. Three packets, one round-trip. The time is bounded by geography:

  • London to Frankfurt: ~10–15 ms.
  • London to New York: ~56 ms (per High Performance Browser Networking, speed of light through fiber).
  • London to California: ~100 ms.

After the handshake, TCP’s initial congestion window (IW=10, per RFC 6928) allows up to 10 packets (~14.6 KB) in flight without waiting for ACKs. The first response must fit in the IW or Bea must wait for an ACK before receiving more — one hidden reason why keeping HTML under 14 KB matters.

Optimisation: preconnect. <link rel="preconnect" href="//fonts.googleapis.com" crossorigin> tells the browser to open TCP + TLS to anticipated origins before the main parser reaches them. Right pattern: apply to two or three critical origins (CDN, fonts, API), not all origins.

Phase 3: TLS 1.3 handshake (1 RTT new, 0 RTT resumed)

Bea sends ClientHello (key share, cipher suites). Sven responds ServerHello (chosen cipher, certificate, server key share). Bea validates the certificate against Cara’s signature. Both derive shared keys. Cost: one round-trip (~25 ms regional). If Bea has seen Sven before, she sends a pre-shared key (PSK) from the session ticket cached on her last visit. Sven accepts without sending the certificate again. Cost: zero additional round-trips — the TLS handshake piggybacks onto the existing QUIC or TCP connection.

0-RTT data. On TLS 1.3 with 0-RTT resumption over QUIC (HTTP/3), Bea can send her HTTP request inside the same initial QUIC packet as the TLS ClientHello — before the server has responded. This saves one RTT on warm connections. 0-RTT is only safe for idempotent methods (GET, HEAD, OPTIONS). For POST or PUT, 0-RTT exposes replay risk (an attacker who captures the encrypted packet can re-send it). Servers must reject 0-RTT for state-changing methods with 425 Too Early.

Edge cases

Connection coalescing: if two origins share the same IP and certificate (e.g., api.example.com and cdn.example.com served behind the same Cloudflare edge), a browser may reuse one HTTP/2 or /3 connection for both. This eliminates the TCP + TLS handshake for the second origin entirely. Coalescing happens silently; you benefit from it if you host multiple subdomains behind one CDN.

Trace it
1/5

Trace a complete first-visit page load from cold cache to TTFB.

1
Step 1 of 5
User types URL. What happens in the browser first?
2
Locked
DNS returns the IP. What happens next?
3
Locked
TCP done. TLS begins. What does Bea send first?
4
Locked
Sven responds with ServerHello + Certificate. What does Bea check?
5
Locked
TLS done. Bea sends the HTTP request. Server processes and returns first byte. Total TTFB?
Trace it
1/5

Trace the same site 30 minutes later — warm cache.

1
Step 1 of 5
DNS cached at OS resolver. How long does DNS take?
2
Locked
TCP — what changes for the warm connection?
3
Locked
TLS — what changes?
4
Locked
Static assets. What does the browser do for cached resources?
5
Locked
Total time to LCP on a warm load?
Quiz

0-RTT resumption saves a round-trip but is unsafe for POST requests. Why?

Order the steps

Order these optimisations by the number of round-trips they eliminate (most to fewest):

  1. 1 CDN edge cache hit (eliminates DNS + TCP + TLS + origin round-trip)
  2. 2 TLS 0-RTT resumption (eliminates 1 TLS RTT)
  3. 3 Connection keep-alive (eliminates TCP handshake for subsequent requests)
  4. 4 dns-prefetch (moves DNS off the critical path, does not eliminate a round-trip)
Recall before you leave
  1. 01
    Explain why TLS 1.3 0-RTT saves a round-trip but is dangerous for non-idempotent requests.
  2. 02
    What is the TCP initial congestion window (IW=10) and why does it matter for page load?
  3. 03
    Why does `<link rel=preconnect>` to ten origins harm more than it helps?
Recap

The first three phases — DNS, TCP, TLS — are strictly sequential and together account for 100–175 ms on a first visit. Each can be reduced by geography (CDN edge) or eliminated by caching (DNS TTL, connection keep-alive, TLS session resumption). On a warm return visit, all three can collapse to under 1 ms total by reusing the OS DNS cache, a pooled connection, and a TLS PSK. HTTP/3 0-RTT goes further, piggybacking the HTTP request onto the TLS ClientHello — but only safely for idempotent methods. The TCP initial congestion window of 10 packets (~14.6 KB) is a hidden threshold: responses exceeding it pay an extra round-trip before the server can send more data.

Connected lessons
appears again in258
Continue the climb ↑Critical render path and Core Web Vitals
shortcuts expand
search
K
prev piece
k
next piece
j
cycle tier
t
this menu
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.