Clicking a link does not fetch a page; it negotiates a secure tunnel before a single byte of content moves.
When a browser resolves a URL, it does not speak directly to the server. It speaks to the Domain Name System, then the Transmission Control Protocol, then the Transport Layer Security specification defined by the IETF. Each step adds latency. The total budget for a modern HTTPS page load on a stable connection is often under 100ms. This budget is not consumed by drawing pixels. It is consumed by handshakes.
The browser must verify identity before it trusts the data. It must establish a path before it sends a message. The IETF published RFC 8446 to standardize the TLS 1.3 protocol, which reduced the cryptographic exchange from two round trips to one. Even with this efficiency, the physics of the network impose a hard floor. Light travels at finite speed through fiber optic cables. Packets must be processed by routers at every hop. The time measured in Chrome Developer Tools is not just processing time; it is travel time.
The handshake mechanics
The process follows a strict sequence. First, the browser asks for the server’s address. Second, it establishes a connection. Third, it negotiates encryption keys. Fourth, it requests the document. Fifth, the server sends the document.
Each step requires a round trip between the client and the server. A round trip is the time for a packet to leave the computer, reach the server, and for an acknowledgment to return. In a local network, this is negligible. On a global connection, this is the dominant factor. Cloudflare Radar tracks global latency and reports median round-trip times between 50ms and 150ms depending on geographic distance. The browser cannot proceed to the next step until the previous step confirms completion.
| Step | Protocol | Time Budget (ms) | Crypto Work |
|---|---|---|---|
| DNS Lookup | UDP | 20 | None |
| TCP Handshake | TCP | 30 | None |
| TLS Handshake | TLS 1.3 | 30 | Key Exchange (ECDHE) |
| HTTP Request | HTTP/2 | 10 | None |
| Server Response | HTTP/2 | 10 | AES-GCM Decryption |
The table above assumes a 100ms total budget. The DNS lookup consumes 20ms. The TCP handshake consumes 30ms. The TLS handshake consumes 30ms. The HTTP request and response share the final 30ms.
The DNS lookup is the first barrier. The browser sends a query to a recursive resolver, often operated by the ISP or a public provider like Google or Cloudflare. The resolver returns an IP address. This step usually uses UDP, which does not guarantee delivery. If the packet is lost, the browser retries, adding latency.
The TCP handshake establishes reliability. The client sends a SYN packet. The server responds with a SYN-ACK. The client sends an ACK. This three-way handshake ensures both sides agree on sequence numbers before data transfer begins. It consumes one full round trip.
The TLS handshake is the trust layer. The client sends a ClientHello. The server responds with a ServerHello, its certificate, and its key share. The client verifies the certificate against a trusted root store. It then generates a shared secret using Elliptic Curve Diffie-Hellman (Ephemeral) key exchange. This happens in the same round trip as the ServerHello in TLS 1.3. In TLS 1.2, this required an additional round trip. The IETF removed this step to reduce latency.
The HTTP request asks for the resource. The server begins generating the response. The server sends a 200 OK status followed by the body. If the content is large, the browser downloads it in chunks. The first byte arrives after the handshake completes.
The security-speed tradeoff
Of the 100ms budget, the handshake consumes 80ms. The actual content transfer consumes the remaining 20ms. This is the inverse of intuition: most users assume the page is slow because the server is generating HTML slowly. In reality, the server is ready. The network is negotiating trust.
TLS 1.3 (RFC 8446) cut handshake latency in half by combining steps. The ServerHello, certificate, and key share now arrive together, eliminating the second round trip TLS 1.2 required. Stronger ciphers cost CPU; smarter protocol design recovers RTTs. The latter is the bigger lever.
The closer
The TLS handshake consumes 80ms of a 100ms budget — eight times more than the actual content transfer. Removing handshake round trips is the highest-leverage optimization a network engineer can make, and the only one that scales with the speed of light rather than CPU performance. A CDN node in the same city as the user can cut the round-trip from 50ms to 10ms, dropping the handshake budget from 80ms to 20ms. That is why the answer to “make HTTPS faster” is almost never “buy a faster server” — it is “move the server closer.” The bill is paid in distance, not in CPU cycles.