What actually happens in the half-second after you hit Enter.
Every website visit is a relay race between three machines: your browser, a DNS resolver, and the web server. Step through each packet below — the milliseconds are real, and you can make the network slower to feel why distance matters.
Drag to rotate · the pulse is your packet
Ready
Press Step to send the first packet: a DNS query asking “what IP address is example.com?”
The six phases, with the math
At a 40 ms round-trip time (RTT — a typical same-continent connection), a cold page load spends roughly one RTT per phase before a byte of HTML arrives:
| Phase | What travels | Cost |
|---|---|---|
| 1. DNS lookup | UDP query to resolver → IP answer | ~1 RTT (0 if cached) |
| 2. TCP handshake | SYN → SYN-ACK → ACK | 1 RTT |
| 3. TLS 1.3 handshake | keys exchanged, connection encrypted | 1 RTT |
| 4. HTTP request | GET / HTTP/2 | ½ RTT |
| 5. Server think time | app renders the response | ~50 ms |
| 6. Response + render | HTML → parse → paint | ½ RTT + parse |
Worked example: total ≈ 3 × RTT + 50 ms server time. At 40 ms RTT that’s ~170–210 ms to first byte; at 200 ms (another continent, no CDN) it balloons past 650 ms before anything paints. This is the entire business case for CDNs: move the server closer, shrink every RTT at once.
Why this is worth knowing
DNS is a phonebook, not a wire. It maps names to IP addresses (example.com → 93.184.216.34) and its answers are cached at your device, router, and ISP — which is why the second visit skips phase 1 entirely.
TLS is why the padlock exists. Since TLS 1.3 (2018), setting up encryption costs just one round trip, and resumed connections cost zero. There is almost no performance excuse left for plain HTTP.
The render is usually the slow part. Networks account for a few hundred milliseconds; multi-megabyte JavaScript bundles account for the rest. A page that ships 200 KB of HTML/CSS can paint in under half a second worldwide — a lesson most modern sites ignore.