How does the World Wide Web actually work from URL to rendered page?

Typing a URL triggers: DNS resolution → TCP/TLS connection → HTTP request → server response → browser parses HTML, builds the DOM/CSSOM, runs JS, fetches subresources, renders, and paints. Underneath: the client-server model over HTTP, DNS, IP routing, and TCP/IP.

6 min read·~8 min to think through

"How the web works" is the end-to-end journey from typing a URL to seeing a page. The classic interview walkthrough:

1. URL → IP address (DNS)

The browser needs the server's IP. It checks caches (browser → OS → router → ISP resolver); on a miss, a recursive DNS lookup walks root → TLD (.com) → authoritative nameserver to resolve example.com → an IP.

2. Establish a connection

TCP handshake (SYN / SYN-ACK / ACK) to the server's IP:port — a reliable connection. (HTTP/3 uses QUIC over UDP instead.)
TLS handshake for HTTPS — negotiate encryption, exchange/verify the certificate. Now the channel is secure.

3. HTTP request / response

The browser sends an HTTP request: method (GET), path, headers (cookies, Accept, User-Agent), maybe a body.
The request may pass through CDNs, load balancers, reverse proxies before reaching an app server.
The server processes it (routing, app logic, DB queries) and returns an HTTP response: status code, headers (Content-Type, Cache-Control, Set-Cookie), and the body (HTML).

4. Browser renders the page

Parse HTML → DOM tree.
Parse CSS → CSSOM.
As it parses, it discovers subresources (CSS, JS, images, fonts) and fetches them — each potentially repeating steps 1–3 (DNS/connection/request).
JavaScript executes (can block parsing unless async/defer) and can modify the DOM.
DOM + CSSOM → render tree → layout (geometry) → paint → composite → pixels on screen.

5. The page is interactive

JS event handlers wired up; further requests (XHR/fetch) happen as the user interacts; the page may update without full reloads (SPA).

The underlying model & protocols

Client–server model — browsers (clients) request, servers respond.
HTTP — the application-layer request/response protocol (stateless; cookies/tokens add state).
DNS — the web's phone book, name → IP.
TCP/IP — reliable, ordered delivery (TCP) over packet routing across networks (IP).
TLS — encryption layer for HTTPS.
URLs — scheme://host:port/path?query#fragment — uniquely address resources.

How to answer

Walk it linearly — DNS → TCP/TLS → HTTP request/response → parse/render/paint — and name the protocols at each layer (DNS, TCP/IP, HTTP, TLS). Mention caching (DNS cache, HTTP cache, CDN) and that subresource fetches repeat the cycle. Going deeper on any one step (the critical rendering path, the TLS handshake) shows depth.

Follow-up questions

•Walk through the critical rendering path in more detail.
•What happens in a TLS handshake?
•How does DNS caching work at each level?
•What's the difference between HTTP/1.1, HTTP/2, and HTTP/3?

Common mistakes

•Skipping DNS or the connection setup and jumping straight to 'the server sends HTML'.
•Confusing TCP, HTTP, and TLS — what each layer does.
•Not mentioning that subresources repeat the request cycle.
•Ignoring caching at multiple layers.

Performance considerations

•Each round-trip (DNS, TCP, TLS, HTTP) adds latency — caching, keep-alive, HTTP/2 multiplexing, CDNs, and preconnect/dns-prefetch all cut it. The render path (parse, layout, paint) is where frontend perf work lives.

Edge cases

•Cached DNS / HTTP responses short-circuiting steps.
•Redirects (3xx) adding round-trips.
•CDN edge serving without hitting the origin.
•HTTP/3 over QUIC/UDP instead of TCP.

Real-world examples

•The canonical 'what happens when you type a URL and press Enter' interview question.

Senior engineer discussion

Seniors give a clean layered walkthrough — DNS, TCP/TLS, HTTP request/response, parse/render/paint — name the protocol at each layer, and weave in caching (DNS, HTTP, CDN) and that subresources repeat the cycle. They can zoom into any step (critical rendering path, TLS handshake, HTTP versions) on demand.