The four phases
- DNS lookup — turning the hostname into an address. Owned by your DNS provider and the client's resolver. Usually a few milliseconds when cached; tens or hundreds when the record's TTL has expired or the authoritative servers are slow.
- TCP connect — the handshake with the address DNS returned. It costs one round trip, so it is a direct reading of network distance: a few milliseconds within a region, 70–150 ms across an ocean.
- TLS handshake — certificate exchange and key agreement for HTTPS. One more round trip with TLS 1.3, two with 1.2, plus whatever the terminating server spends on cryptography. Owned by whoever terminates TLS: a load balancer, an API gateway, a CDN edge.
- Server wait — from the request being sent to the first byte of the response. This is your application (or the function, or the upstream it calls) doing the work. Cold starts of serverless functions land here.
Add them up and you have time to first byte. A request that reuses an open connection skips the first three entirely — which is why a "warm" benchmark from your laptop can look nothing like a customer's first request.
Reading a breakdown
- Server wait grew, everything else flat — the application, its database or an upstream dependency. Not the network, not the cloud provider's edge.
- TCP connect grew — the path got longer: traffic is being routed to a farther region, or across a congested link. Check where the address now points.
- TLS grew, TCP did not — the terminating server is struggling (CPU, certificate chain size, OCSP), or a configuration change downgraded the protocol version.
- DNS spikes on a schedule — a short TTL meeting slow authoritative servers; every expiry costs a full lookup.
Measuring it
From a terminal, curl reports the cumulative points:
curl -o /dev/null -s -w 'dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n' https://api.example.com/healthEach value is measured from the start, so subtract the previous one to get a phase. Run it a few times: the first run includes a cold DNS lookup, later ones may not.
For monitoring, the same split needs to be recorded on every scheduled check and kept, so a regression in one phase shows up against its own history instead of disappearing inside a total that "only" grew by 20%.