What Happens When You Type a URL
Prompt
You type a URL, hit Enter, and a page appears. Walk me through everything that happens between those two moments — the whole path, network through render — and I'll stop you to go deeper wherever it gets interesting.
How this round runs
This is a conversation that escalates — I'll keep asking "and what happens when…" until I find the edge of what you know. This question spans every layer, so I'm watching whether you can move cleanly from DNS to TCP to TLS to HTTP to render and connect them — and stay honest about where your depth runs out — rather than reciting a flat checklist.
Model answer
I'll walk it layer by layer, naming the hand-off between each, because the connections are the point. First name resolution: the browser parses the URL, checks its own and the OS's DNS cache, and on a miss asks a recursive resolver, which chases root → TLD → authoritative nameservers to get an IP. Then transport: a TCP three-way handshake (SYN / SYN-ACK / ACK) to that IP synchronizes sequence numbers so delivery is reliable. On top of that, TLS for HTTPS — in 1.3 a 1-RTT handshake where the client's optimistic key-share lets both sides derive a shared key, and the browser validates the server's certificate (chain of trust, validity, and hostname binding) before trusting it.
Now HTTP: the browser sends a GET for the path; the server responds, ideally 200 with
HTML — but a 301/302 here sends us back to resolve a new URL, and cache headers may mean
we skip the network entirely. The browser parses the HTML into a DOM, and as it parses it
discovers subresources — CSS, JS, images — and fetches them, CSS being render-blocking (it
needs the full CSSOM before it can paint) and synchronous scripts blocking the parser unless
async/defer. It builds the DOM and CSSOM, combines them into the render tree, then
layout computes geometry, paint fills pixels, and compositing assembles layers
into the frame you see.
Where I'd be honest about depth: the network layers I can reason through end to end; the render pipeline I know at the DOM → CSSOM → render-tree → layout → paint → composite level, but the exact paint/raster/GPU-compositing internals and the precise main-thread-vs-compositor split are where I'd say "I know the shape, I'd verify the specifics." The thread to pull next, if you want it, is connection reuse: HTTP/2 multiplexes many requests over the one TLS connection, so subresource fetches don't each pay a fresh handshake — which is exactly the cost the older one-connection-per-request model imposed.
- Moved cleanly across layers — DNS → TCP → TLS → HTTP → parse → render — naming the hand-off between each
- Mentioned cross-cutting realities: redirects re-enter resolution, cache headers can skip the network, CSS is render-blocking
- Got the render pipeline order right: DOM + CSSOM → render tree → layout → paint → composite
- Connected layers to consequences (TLS cert validation before trust; async/defer unblocking the parser)
- Honest boundary on the deepest paint/compositing internals instead of bluffing them
- Mid-session a cached DNS record's TTL expires — what happens to the in-flight connection? → nothing to the live TCP connection; the IP was already resolved, TTL only governs the NEXT lookup
- How does HTTP/2 change the subresource fetch story versus HTTP/1.1? → multiplexes many streams over one TLS connection, killing head-of-line blocking at the HTTP layer and avoiding per-request handshakes
- And what happens when a synchronous script tag sits in the middle of the HTML? → it blocks the parser until fetched and executed; async/defer let parsing continue