How the Web Works
The 200ms journey from typing a URL to seeing pixels — the map every other web topic hangs off.
30 minDifficulty 1/5fundamentals · networkingReviewedRead and accepted by a person.
Why this exists
"What happens when you type a URL and press enter?" is the most-asked interview question in web development, and it isn't asked because the answer is useful trivia. It's asked because the answer is a *map* — every layer you'll ever debug appears somewhere in it, and knowing where they sit tells you where to look when something breaks.
The mental model
Posting a letter internationally. Look up the address, establish a route, agree on a private language, send the request, get a package back, then unpack it — and discover the package contains instructions to fetch several more packages.
How it works
Name to address: DNS
Computers route by IP address, not by name, so the hostname must be resolved first. The browser checks its own cache, then the OS cache, then asks a resolver, which walks the DNS hierarchy if nobody has the answer. Caching at every level is why this is usually instant — and why a DNS change takes time to propagate, which is the source of the classic "it works on my machine but not on my colleague's" after a deploy.
Connect and agree on secrecy: TCP and TLS
A TCP connection is established with a three-way handshake — one round trip. For HTTPS, a TLS handshake follows: the server presents a certificate proving it owns the domain, the two sides agree on encryption keys. That's another one or two round trips. This is why latency matters so much more than bandwidth for page load: several round trips happen before a single byte of your content moves, and no amount of bandwidth makes the speed of light faster.
Ask and receive: the HTTP exchange
Now the actual request goes out — a method, a path, and headers. But it rarely reaches your server directly. It typically passes through a CDN edge, then a load balancer, then a reverse proxy, and only then your application. Each hop can answer on its own: a CDN might return a cached copy and your server never learns the request happened. Knowing this chain exists is what stops you debugging your application code for an hour when the stale response is coming from a cache two layers up.
Render, and discover more work
The browser parses HTML into the DOM as it arrives, and each `<link>`, `<script>` and `<img>` triggers another request. CSS blocks rendering, because painting text that then restyles would look broken. Classic `<script>` tags block parsing, because they might write into the document — which is what `defer` and `async` exist to avoid. The first response is the start of the work, not the end of it.
The mechanism
Where the time actually goes on a typical first load: | Stage | Typical cost | |---|---| | DNS | 0–100ms (usually cached) | | TCP handshake | 1 round trip | | TLS handshake | 1–2 round trips | | Request → first byte | 1 round trip + server time | | Subresources | more requests, mostly parallel | On a 100ms-latency connection you've spent 300–400ms before any content arrives. This is why CDNs work: moving the server closer shortens every round trip at once, which helps far more than making the server faster.
sequenceDiagram
participant U as Browser
participant D as DNS
participant C as CDN edge
participant L as Load balancer
participant S as Your server
U->>D: resolve example.com
D-->>U: 93.184.216.34
U->>C: TCP + TLS handshake
U->>C: GET / HTTP/2
alt cached at the edge
C-->>U: 200 (server never sees it)
else not cached
C->>L: forward
L->>S: route to an instance
S-->>L: 200 + HTML
L-->>C: 200
C-->>U: 200 + cache it
end
U->>U: parse HTML, build DOM
U->>C: GET /app.css, /app.js, /logo.pngWhat people get wrong
- The browser talks directly to my server.
- It usually talks to a CDN edge, which talks to a load balancer, which talks to one of your instances. Any hop can serve a cached response or rewrite headers. Debugging the app first, when the answer came from a cache, wastes a lot of time.
- Faster internet means faster page loads.
- Beyond a modest threshold, latency dominates, not bandwidth. Page load is a sequence of dependent round trips. More bandwidth doesn't shorten a round trip.
- HTTPS just encrypts the data.
- It also authenticates the server, via a certificate chain, and detects tampering. Encryption without authentication would let an attacker in the middle encrypt to themselves. The certificate is what makes the encryption meaningful.
- Once the HTML arrives, the page is loaded.
- The HTML is a manifest. CSS, JS, fonts and images are separate requests, and CSS and synchronous scripts block rendering. Time-to-first-byte and time-to-interactive can differ by seconds, which is why one metric alone never tells the story.
When not to use it
- You need to know exactly where time went for a specific real user.
- Real user monitoring and the Navigation Timing API. This model tells you what the stages are; measurement tells you which one hurt.
- You're debugging a local-only issue with no network involved.
- Most of this chain doesn't apply. Knowing which layers are absent is as useful as knowing which are present.
Terms
- DNS
- — The system translating hostnames into IP addresses.
- Round trip (RTT)
- — The time for a packet to reach the server and a reply to return. The unit page load is actually measured in.
- TLS handshake
- — The negotiation establishing encryption keys and verifying the server's certificate.
- CDN
- — Geographically distributed caches that serve content from near the user.
- Load balancer
- — Distributes incoming requests across multiple server instances.
- TTFB
- — Time to first byte — how long until the first byte of the response arrives.
- Render-blocking
- — A resource the browser must fetch before it can paint. CSS and synchronous scripts qualify.
In an interview
What happens when you type a URL and press enter?
- DNS resolution, with caching at several levels
- TCP handshake, then TLS for HTTPS
- the HTTP request, passing through CDN, load balancer and proxy
- response parsed into the DOM, triggering subresource requests
- render-blocking behaviour of CSS and synchronous scripts
A page is slow for users in Australia but fast in London, where your servers are. Why?
- latency scales with physical distance and every round trip pays it
- several round trips happen before content arrives
- a CDN edge close to the user fixes this in a way that a faster server cannot
- server-side optimisation is the wrong lever for a latency problem
Can you recall it?
From memory: name the stages between pressing enter and seeing content, and say why latency matters more than bandwidth.
Connected ideas
- DNS — A globally distributed, aggressively cached phone book — and the reason your deploy 'didn't work' for 20 minutes.
- HTTP: Requests & Responses — A stateless text protocol — understand its shape and half of backend work stops being mysterious.
- Load Balancing — Spreading traffic across machines, and what breaks the moment there's more than one.