Learn the theory
What Happens When You Type a URL: how it works
5 min read · Updated
Before a single byte of your page arrives, the browser has to find the server, open a connection and agree on encryption. Each of those steps costs round trips, and round trips are bounded by the speed of light — a request to another continent can spend several hundred milliseconds just on handshakes. Seeing where that time goes is the key to understanding TTFB (time to first byte), CDNs, keep-alive, TLS 1.3 and HTTP/3.
In short
- The sequence is DNS → TCP → TLS → HTTP, and each step must finish before the next begins.
- DNS is a hierarchy (resolver → root → TLD → authoritative) that is cached heavily at every layer.
- TCP needs 1 round trip to connect; TLS 1.2 adds 2, TLS 1.3 adds 1, and HTTP/3 (QUIC) merges both into 1.
- Connection reuse (keep-alive, HTTP/2 multiplexing) skips all handshakes for later requests.
- The cure for latency is fewer round trips and shorter distances (CDNs, edge servers).
The whole journey
When you press Enter on https://example.com, the browser runs through these phases in order:
- DNS lookup — turn the hostname into an IP address.
- TCP handshake — open a reliable connection to that IP (SYN, SYN-ACK, ACK).
- TLS handshake — agree on encryption keys and verify the server's certificate.
- HTTP request/response — send
GET /and wait for the first byte of the answer.
The delay until that first byte arrives is the TTFB. It is the floor under every other page-load metric.
DNS: finding the server
The browser first checks its own cache and the operating system's. If neither knows the answer it asks a recursive resolver (your ISP's, or a public one like 1.1.1.1 or 8.8.8.8), which does the legwork:
- Ask a root server: “who handles
.com?” → referral to the.comTLD servers. - Ask a TLD server: “who handles
example.com?” → referral to the domain's name servers. - Ask the authoritative name server: “what is the A record for
example.com?” → the IP address.
Each answer carries a TTL (time to live) saying how long it may be cached. Popular domains are almost always cached at the resolver, so most real lookups cost a single short round trip to the resolver.
| Record | Purpose |
|---|---|
| A / AAAA | Hostname → IPv4 / IPv6 address |
| CNAME | Alias to another hostname |
| NS | Which servers are authoritative for a zone |
| MX / TXT | Mail routing, verification, SPF/DKIM |
TCP: opening a reliable connection
TCP's three-way handshake establishes sequence numbers on both sides: the client sends SYN, the server replies SYN-ACK, the client sends ACK. The client can start sending data right after its ACK, so the real cost is one full round trip before encryption can even begin.
TLS: encryption and identity
TLS lets the browser verify it's really talking to example.com (through the server's certificate chain) and agree on a shared secret key. The handshake length depends on the version:
| Version | Round trips | Notes |
|---|---|---|
| TLS 1.2 | 2 | ClientHello → ServerHello + certificate → key exchange → Finished. Older, still common. |
| TLS 1.3 | 1 | The client guesses the key-exchange parameters in its first message, so one round trip is enough. Removes insecure legacy options. |
| TLS 1.3 resumption (0-RTT) | 0 | Returning clients can send data immediately, with some replay-attack caveats. |
HTTP/1.1, HTTP/2 and HTTP/3
| Version | Transport | Key idea |
|---|---|---|
| HTTP/1.1 | TCP + TLS | One request at a time per connection; browsers open ~6 connections in parallel and suffer head-of-line blocking. |
| HTTP/2 | TCP + TLS | Multiplexes many requests over one connection and compresses headers — but a lost TCP packet still stalls all streams. |
| HTTP/3 | QUIC (UDP) | Merges transport and crypto handshakes (1 RTT), with independent streams so one lost packet doesn't block the others. |
Connection reuse and keep-alive
Handshakes are only needed for a new connection. With keep-alive (HTTP/1.1) and multiplexing (HTTP/2 and 3), later requests to the same origin ride the existing connection and skip DNS, TCP and TLS completely. This is why the first request to a site feels slower than the rest — and why preconnect hints help.
<!-- Do DNS + TCP + TLS early for a host you'll need soon -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://analytics.example.com">Measuring it yourself
# Per-phase timings from curl
curl -o /dev/null -s -w \
"dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
https://example.com
# Walk the DNS hierarchy
dig +trace example.comIn Chrome DevTools, the Network panel's Timing tab shows the same breakdown: DNS Lookup, Initial connection, SSL, Waiting for server response (TTFB) and Content Download.
How to make it faster
- Serve from the edge. A CDN shortens every round trip by moving the server closer to the user.
- Enable TLS 1.3 and HTTP/2 or HTTP/3 to cut handshake round trips.
- Reuse connections and avoid scattering assets across many hostnames.
- Use a good DNS provider and sensible TTLs, and
preconnectto critical third parties. - Cache aggressively so repeat visits skip the network entirely.
Frequently asked questions
- What happens when you type a URL into the browser?
- The browser resolves the hostname through DNS, opens a TCP connection, performs a TLS handshake (for HTTPS), sends an HTTP request and waits for the response. Caches at each layer can skip steps.
- What is the TCP three-way handshake?
- SYN, SYN-ACK, ACK: the client proposes a connection, the server acknowledges and proposes its side, and the client confirms. It costs one round trip before data can flow.
- How many round trips does TLS 1.3 save compared to TLS 1.2?
- One. TLS 1.3 completes its handshake in a single round trip, while TLS 1.2 needs two.
- What is TTFB?
- Time to first byte: the time from starting the request until the first byte of the response arrives. It includes DNS, connection setup, TLS and the server's processing time.
- Why is the first request to a site slower than later ones?
- The first request pays for DNS, TCP and TLS handshakes. Later requests reuse the cached DNS answer and the open connection, so only the HTTP exchange remains.
- What makes HTTP/3 faster?
- HTTP/3 runs over QUIC, which combines the transport and encryption handshakes into one round trip and avoids TCP's head-of-line blocking, so a single lost packet doesn't stall every stream.