Part 1
The journey of a request
From typing an address to reaching the right machine.
01 What happens when you press Enter
Loading a page takes four separate systems working together: your browser, DNS, the network, and a server somewhere in the world. This chapter is the map; the rest of the guide zooms in on each stop.
You type example.com and press Enter. Before a single pixel changes, four separate systems are going to take part — and most of the time it all happens in well under a second.
02 DNS: names into addresses
Computers connect to IP addresses, not names. DNS finds the address for a name by asking a chain of servers — the root, then the .com servers, then the domain's own — and caches every answer so most lookups never make the full trip.
DNS turns a name like example.com into an IP address. No single server knows every name — the answer is found by asking a chain of servers, each responsible for one part of the name.
Part 2
The conversation
How the browser and server talk, privately.
03 HTTPS and the TLS handshake
Before any page data is sent, browser and server agree on a secret key that nobody listening can work out, and the server proves it really is the site you asked for with a certificate. That's the padlock.
HTTPS is HTTP sent through a TLS connection. Before any HTTP is sent, client and server need two things: a shared secret key that nobody listening could know, and proof that the server is really example.com.
04 HTTP requests and responses
Every page, image and API call is the same exchange: a request with a method (GET, POST…), a path and headers, and a response with a status code, headers and a body.
HTTP is a request/response protocol: the client sends one request, the server sends back one response. Both are mostly plain, readable text.
Part 3
Memory, safety, and speed
How sites remember you, protect you, and avoid repeating work.
05 Cookies and sessions
HTTP forgets you after every request. A cookie is a small value the browser sends back automatically each time — usually a random session ID the server uses to look up who you are.
HTTP is stateless: each request stands alone, and the server doesn't remember you between them. Cookies are how the browser carries a little state back every time.
06 CORS and the same-origin policy
A page may send requests anywhere, but it can only read responses from its own origin — unless the other server says otherwise with CORS headers. It stops one site reading your data on another.
A page on app.example wants data from api.example. The two have different origins (scheme + host + port), so the browser applies the same-origin policy — and CORS is the way a server relaxes it.
07 HTTP caching
The fastest request is the one never sent. Cache-Control says how long a response can be reused as-is, and an ETag lets the browser cheaply check whether a stale copy is still good.
The fastest request is the one never sent. HTTP caching lets the browser keep responses and reuse them — controlled entirely by headers the server sends.
Part 4
Building on HTTP
How programs talk to each other — and keep talking.
08 APIs, REST, and JSON
An API is a set of requests a server agrees to answer for other programs. A REST API uses URLs for things, HTTP methods for actions, and JSON for data — so your app never touches the database directly.
An API is a set of requests one program agrees to answer for another. A web API is usually just HTTP: your app sends requests to URLs, and gets structured data — usually JSON — back.
09 Real-time: polling, SSE, and WebSockets
Plain HTTP only answers when asked. For chat, live scores and notifications, the browser either asks repeatedly, keeps a response open for the server to stream into, or upgrades to a WebSocket — a connection either side can send on at any time.
WebSocket: one TCP connection upgraded out of HTTP into a two-way message channel.
Part 5
From bytes to pixels
What the browser does with the HTML once it arrives.
10 The DOM
The browser parses HTML into a tree of objects — the DOM. That tree is what's drawn on screen, and it's what JavaScript reads and changes.
HTML is just text. The browser reads it top to bottom and builds a tree of objects in memory — the DOM (Document Object Model). That tree, not the text, is what you see and what JavaScript changes.
11 Style, layout, paint, composite
To draw the tree, the browser works out each element's styles, computes where every box goes, paints the pixels, and composites the layers. Some changes redo all of it; transform and opacity can skip straight to the end.
Every visual change runs through the same pipeline. Which stages it reaches decides whether a frame costs microseconds or milliseconds.