You type "google.com" and press Enter. A page appears. Feels instant. But in that blink — roughly 2 seconds — your browser just orchestrated a relay race across dozens of machines spanning multiple continents.
I find it genuinely wild that most web developers ship code every day without knowing what happens between keystroke and pixel. So here's the full chain, no hand-waving.
Step 1: DNS — Translating Names to Numbers
Your browser doesn't know what "google.com" means. Computers speak IP addresses, not words. So the first job is translation.
The browser checks its own cache first. Then the OS cache. Then your router's cache. If nobody has the answer, the query goes to a recursive DNS resolver — usually run by your ISP or a service like Cloudflare (1.1.1.1) or Google (8.8.8.8).
That resolver walks the DNS hierarchy: root server → .com TLD server → Google's authoritative nameserver. Each step narrows down until someone says "google.com lives at 142.250.70.14." The whole lookup typically takes 20-120 milliseconds.
Fun fact: there are only 13 root server addresses in the entire DNS system. They handle billions of queries daily through anycast routing — the same IP address served from hundreds of physical locations worldwide.
Step 2: TCP — The Three-Way Handshake
Now your browser knows where to go. But before sending any data, it needs a reliable connection. That means TCP.
TCP uses a three-way handshake:
- SYN — your browser says "I want to talk"
- SYN-ACK — the server replies "acknowledged, let's go"
- ACK — your browser confirms "we're connected"
Three packets, just to say hello. This adds another round-trip of latency — typically 10-50ms for a nearby server, more for distant ones.
Step 3: TLS — Encrypting Everything
If the site uses HTTPS (and 95%+ of the web does now), there's another handshake on top of TCP. TLS negotiation involves:
- Your browser sending supported cipher suites
- The server picking one and sending its certificate
- Your browser verifying that certificate against trusted Certificate Authorities
- Both sides generating session keys for encryption
TLS 1.3 streamlined this to a single round-trip. Older TLS 1.2 needed two. Either way, every byte after this point is encrypted. Nobody between you and the server — not your ISP, not the coffee shop WiFi owner — can read the content.
Step 4: HTTP — The Actual Request
Finally, your browser sends the HTTP request: GET / HTTP/2. The server processes it, pulls the HTML, and sends it back. Modern HTTP/2 multiplexes multiple requests over a single connection, so your browser can fetch HTML, CSS, JavaScript, and images simultaneously instead of queuing them up one by one.
Step 5: Rendering — Turning Code into Pixels
The browser parses HTML into a DOM tree, CSS into a CSSOM tree, merges them into a render tree, calculates layout (where everything goes on screen), and paints pixels. JavaScript can interrupt this entire process, which is why a badly-placed script tag can freeze your page.
Chrome's rendering engine (Blink) does all of this in under 100ms for a typical page. The entire journey — DNS, TCP, TLS, HTTP, render — happens in about 1-2 seconds. Often less.
Why This Matters
Understanding this chain isn't just trivia. It's how you debug real problems. Slow TTFB? Probably server-side. Slow page load with fast TTFB? Look at render-blocking resources. Random timeouts? Could be DNS or TLS certificate issues.
Every performance optimization targets one of these steps. CDNs shorten the physical distance (faster TCP). DNS prefetching eliminates lookup time. HTTP/2 push sends assets before the browser asks. Code splitting reduces what the browser needs to parse.
Two seconds. Dozens of machines. Billions of times a day. The internet is absurdly complex — we've just gotten really good at hiding it.
Top comments (0)