It is the most famous interview question in web development, and it deserves better than a memorised list: what happens between pressing Enter on a URL and seeing the page? The honest answer is a relay race across half the disciplines of computing — naming, routing, cryptography, parsing, layout — each leg measured in milliseconds. Understanding the legs is what turns performance work from cargo culting into engineering.
Here is the race, run once, in order.
Finding the server: DNS, TCP, TLS
First the name must become an address. The browser asks the operating system, which asks a resolver, which — on a cache miss — walks the DNS hierarchy from root to top-level domain to the site's own nameservers, returning an IP address. Caches at every layer mean the full walk is rare; its result is why the first visit to a domain is slower than the second.
With an address in hand, the browser opens a TCP connection — the three-way handshake, one round trip — and then negotiates TLS, proving the server's identity via its certificate and agreeing on encryption keys, costing another round trip or two. This is why physical distance still matters on the modern web: every handshake is a trip to the server and back, and a server an ocean away charges you for each one. CDNs exist to move those round trips closer to your chair. Newer protocols (HTTP/3 over QUIC) fold parts of these handshakes together, but the shape is the same: naming, then connection, then trust.
The response arrives: parsing and the two trees
The browser now sends the HTTP request and receives HTML — usually compressed, streamed in chunks. Parsing begins immediately, not at the end of the download, and this is where the page's dependency graph unfolds: stylesheets discovered in the head are fetched (they block rendering, because painting without styles would flash unstyled content); scripts without defer/async block parsing itself, which is exactly why script placement folklore exists; images and fonts queue up behind them.
From the HTML the browser builds the DOM tree — the page's structure — and from the CSS the CSSOM — the rules that apply to it. Combined, they yield the render tree: only the visible elements, each with its final computed style. Layout then assigns every box its geometry, and paint fills in the pixels, often on the GPU, in layers so that later scrolling and animation can move cheaply. First paint is the moment the relay's baton crosses into the user's eyes — typically after two DNS-to-TLS handshakes, one HTML round trip, and the critical CSS.
Why this map pays rent
Every performance technique you have ever been told is a move on this map. Preconnect warms the handshakes early; CDNs shorten every round trip; compressing and streaming HTML gets parsing started sooner; defer keeps scripts from blocking the parser; inlining critical CSS shortens the path to first paint; caching skips whole legs of the race on repeat visits. None of it is magic — each trick removes a specific, nameable wait from the story above.
It also explains the mysteries. Why is the site fast locally and slow for users abroad? Round trips. Why did one synchronous analytics script freeze rendering? Parser blocking. Why does the second page load feel instant? Warm DNS, warm connection, warm cache. The next time a page feels slow, don't guess — ask which leg of the relay is dragging, measure it in the browser's network panel, and fix the leg rather than the vibe.