DNS lookups can involve multiple steps (cache checks, recursive resolver, authoritative servers). Because results are cached with a TTL, repeated visits often skip most of the work. But when caches miss—or DNS is misconfigured—everything stalls before the first byte of the site.
TCP sets up a connection using a handshake and provides ordered, reliable delivery. That reliability is great for web content, but it adds latency (extra round trips) and can be sensitive to packet loss.
TLS sits on top of the connection to:
This adds handshake work, but modern TLS plus HTTP/2/HTTP/3 can reduce overall cost by keeping connections alive and multiplexing many requests.
Tradeoff to remember: handshakes add latency, but they enable trust and safer defaults.
Why can a site feel slow even if the server generates responses quickly, especially on a high-latency network?
On high-latency links, each required round trip is expensive. It’s a common trap to blame “slow servers,” but the delay can happen before the server even receives the request: DNS resolution, TCP connection setup, and TLS negotiation can all add waiting time. HTML parsing doesn’t necessarily wait for images; status codes come from the server, not the browser; and caches aren’t uploaded wholesale before a request.