# What Actually Happens When You Open a Web Page
> Type a URL, press Enter: DNS, TCP, TLS, HTTP/2 and HTTP/3, a CDN edge and the browser's rendering path, traced with real dig and curl output.
- Author: Tai Pham Phu
- Published: 14 Nov 2026
- Tags: Web, Networking, Software Design, Learning, Performance
- URL: https://phamphutai.com/2026/11/14/what-happens-when-you-open-a-web-page/
Type `phamphutai.com` into the address bar and press Enter. A page appears. It feels like one action.
It isn't. Before the first word shows up, your browser has asked a chain of servers where the site lives, opened a connection to a machine in another country, agreed on encryption keys with it, checked a certificate, sent a request, received a compressed reply from a cache, and turned that reply into pixels. A dozen separate systems, owned by different organizations, in a fraction of a second.
This post walks through every step, in order, for developers and curious builders. Every term is explained once, and the example is a real site: this one. At the end you'll run the same commands I ran.
---
## The whole journey on one page
Seven steps between pressing Enter and seeing a page; steps 2 to 4 often run before a single byte of the page is sent.
---
## Step 1: Reading the URL, and HSTS
First the browser works out what you typed. Is it a search query or an address? `phamphutai.com` has a dot and no spaces, so it's treated as an address. A full **URL** (Uniform Resource Locator) has parts: a **scheme** (`https`), a **host** (`phamphutai.com`), an optional **port**, a **path** (`/`), and sometimes a query string after `?`.
You didn't type a scheme, so which one? Modern browsers try `https` first. But there's an older safety net called **HSTS** (HTTP Strict Transport Security, RFC 6797). A site sends a header like this:
```
strict-transport-security: max-age=31536000; includeSubDomains
```
That tells the browser: **for the next year (31,536,000 seconds), never talk to this host or its subdomains over plain HTTP.** After the first visit, the browser upgrades every `http://` link to `https://` by itself, before any network traffic happens. The very first visit is still exposed, which is why Chrome maintains an **HSTS preload list** that's built into the browser. Firefox, Safari and Edge use lists based on it. To join, a site needs `max-age` of at least a year, `includeSubDomains` and a `preload` directive. My site sends the first two but not `preload`, so it relies on the normal header plus a redirect from `http` to `https`.
---
## Step 2: DNS, the internet's phone book
Computers on the internet find each other by **IP address**, a number like `104.21.6.41` (IPv4) or `2606:4700:3033::ac43:9ad0` (IPv6). Humans use names. The **Domain Name System** (DNS) turns one into the other.
Four kinds of server are involved:
- **Stub resolver.** A small piece of your operating system. It doesn't know answers; it asks someone who does. It also keeps a short-lived cache.
- **Recursive resolver.** Usually run by your internet provider, or a public one like Cloudflare's `1.1.1.1` or Google's `8.8.8.8`. It does the legwork of finding the answer and caches it for everyone who asks next.
- **Root servers.** The top of the tree. They don't know where `phamphutai.com` is, but they know who runs `.com`. There are 13 root server identities (`a` to `m`) run by 12 independent operators, served from more than 2,000 physical instances around the world.
- **TLD and authoritative servers.** The **TLD** (top-level domain) servers for `.com` know which servers are responsible for `phamphutai.com`. Those **authoritative** servers hold the actual answer. For this site, that's Cloudflare's nameservers.
The recursive resolver walks down the tree, root to TLD to authoritative, then caches the answer so the next person skips the walk.
### Caching and TTL
Every answer comes with a **TTL** (time to live), in seconds, that says how long it may be cached. In the real lookup further down, the `.com` servers say Cloudflare is responsible for `phamphutai.com` with a TTL of 172,800 seconds (two days), while the site's own address has a TTL of 300 seconds (five minutes). Delegations change rarely; addresses can change more often.
**Most lookups never leave your machine or your resolver.** The full walk only happens when nothing along the way has a fresh copy.
### Record types
DNS stores more than addresses. The three you meet first:
| Record | Holds | Example |
|---|---|---|
| **A** | An IPv4 address | `phamphutai.com. 300 IN A 104.21.6.41` |
| **AAAA** | An IPv6 address | `2606:4700:3033::ac43:9ad0` |
| **CNAME** | "This name is an alias for that name" | `blog.example.com` points to `example.netlify.app` |
A CNAME makes the resolver start again with the new name, which adds a lookup. Note that `phamphutai.com` answers with two A records and two AAAA records. The browser can try any of them, and modern clients often race IPv6 and IPv4 and use whichever connects first.
### DNS over HTTPS
Classic DNS travels unencrypted, so anyone on the network path can read or tamper with your lookups. **DNS over HTTPS** (DoH, RFC 8484) sends the same queries inside ordinary encrypted HTTPS requests to a resolver. Browsers like Firefox and Chrome can use it. It hides your lookups from the café Wi-Fi, though the resolver you send them to still sees them.
---
## Step 3: Opening a connection
The browser now has an IP address. Next it needs a reliable channel to that machine.
### TCP: the three-way handshake
**TCP** (Transmission Control Protocol, RFC 9293) turns the internet's unreliable packets into an ordered, reliable stream of bytes. Before any data flows, the two sides agree to talk:
1. **SYN.** Client: "I'd like to connect, here's my starting sequence number."
2. **SYN-ACK.** Server: "OK, here's mine, and I got yours."
3. **ACK.** Client: "Got yours." The client can send data right after this.
That costs one **round trip** (RTT): the time for a message to go there and back. From Đà Nẵng to a data centre in Singapore, that's around 50 milliseconds in my measurements below. You pay it before anything useful happens.
### TLS 1.3: keys and a certificate
Next comes **TLS** (Transport Layer Security), the "S" in HTTPS. It does two jobs: **encrypt** the traffic so nobody in between can read or change it, and **prove** the server really is `phamphutai.com`.
TLS 1.3 (RFC 8446) does this in **one round trip**:
- The client sends a **ClientHello**: supported ciphers, a key share for a key exchange, and two important extensions. **SNI** (Server Name Indication) names the site it wants, because one IP address at a CDN serves thousands of sites. **ALPN** (Application-Layer Protocol Negotiation) lists the HTTP versions it speaks, like `h2` and `http/1.1`.
- The server answers with a **ServerHello** and its own key share. Both sides can now compute the same secret. RFC 8446 puts it plainly: "All handshake messages after the ServerHello are now encrypted." So the server's **certificate**, a signature proving it holds the matching private key, and a **Finished** message all travel encrypted.
- The client checks the certificate: is it for this name, is it in date, and was it signed by a **certificate authority** (CA) the device already trusts? Then it sends its own Finished, plus the request.
TLS 1.2 needed two round trips for the same thing. TLS 1.3 also offers **0-RTT** resumption, where a returning client sends data in its very first message, but the RFC warns that 0-RTT data can be replayed by an attacker, so it's only safe for requests that don't change anything.
The certificate on this site, from the curl output below: issued to `CN=phamphutai.com` by Google Trust Services, valid from 7 November 2026 to 5 February 2027. Short-lived certificates like this are renewed automatically by Cloudflare.
### HTTP/2 and HTTP/3
Inside the encrypted channel, the browser speaks **HTTP**. Which version depends on what ALPN agreed:
| Version | Runs over | Key idea |
|---|---|---|
| **HTTP/1.1** | TCP | One request at a time per connection, so browsers open several connections |
| **HTTP/2** (RFC 9113) | TCP + TLS | Many requests **multiplexed** as streams on one connection; compressed headers |
| **HTTP/3** (RFC 9114) | **QUIC** over UDP | Same streams, but a lost packet only stalls its own stream |
HTTP/2 fixed most of HTTP/1.1's waste, but it inherited one problem from TCP. TCP delivers bytes strictly in order, so one lost packet holds up every stream on the connection until it's resent. This is called **head-of-line blocking**.
**QUIC** (RFC 9000) is a new transport built on UDP. It moves reliability and ordering into each stream, so a lost packet only delays the stream it belonged to. And it merges the transport and TLS 1.3 handshakes into one, so a new connection is ready after a single round trip instead of two. HTTP/3 is HTTP running on top of QUIC.
How does a browser know a site speaks HTTP/3? The site tells it. This site's response includes `alt-svc: h3=":443"; ma=86400`: "HTTP/3 is available on port 443; remember this for a day." The first visit typically uses HTTP/2, and later connections can switch to HTTP/3.
---
## Step 4: The edge, where most of the work is done
That IP address, `104.21.6.41`, isn't a server in my house or a single machine anywhere. It belongs to **Cloudflare**, a **CDN** (content delivery network): a company with data centres in more than 300 cities that sits between visitors and websites.
### Anycast: one address, many places
Cloudflare uses **anycast**. The same IP address is announced from every data centre at once, using **BGP** (Border Gateway Protocol, the system networks use to tell each other which addresses they can reach). Internet routers send your packets along the shortest route they know, so you end up at a nearby data centre without anyone choosing it for you. The `cf-ray` header in a Cloudflare response ends with an airport code for the data centre that served it. My requests from Đà Nẵng came back stamped `SIN`: Singapore.
### Caching at the edge
A CDN keeps copies of files close to visitors. If the Singapore data centre already has the file, it answers immediately: a **cache hit**, shown as `cf-cache-status: HIT`. If not, it's a **miss**, and it fetches the file from the origin first.
### This site's setup
phamphutai.com is a static site built with **Astro**: at build time, every post becomes plain HTML, CSS and a little JavaScript in a `dist` folder. No application server, no database.
That folder is deployed as a **Cloudflare Worker with static assets**. A **Worker** is a small JavaScript function that runs in every Cloudflare data centre, right next to the cache. The configuration (`wrangler.jsonc`) does three things that matter here:
- `"assets": { "directory": "./dist" }` uploads the built site to Cloudflare's asset storage.
- `"run_worker_first": true` makes the Worker run before every request. By default, Cloudflare serves a matching file without running the Worker at all.
- Two **custom domains**, `phamphutai.com` and `www.phamphutai.com`, route traffic to it.
The Worker itself is about 30 lines. In order, it:
1. Redirects `http://` and `www.` requests to `https://phamphutai.com` with a **301** (permanent) redirect, so there's one canonical address for search engines.
2. Adds a trailing slash to paths like `/writing`, again with a 301.
3. For the Markdown copies of posts (`.md` files), adds a `Link: rel="canonical"` header pointing at the HTML page.
4. Otherwise hands the request to the static assets with `env.ASSETS.fetch(request)`.
**So for most requests, the "server" is a cache and a tiny function, a few hundred kilometres from the reader.** That's why a static site on a CDN is so fast and so cheap to run.
---
## Step 5: The HTTP request and response
The browser sends something like this (HTTP/2 encodes it in binary, but the meaning is the same):
```
GET / HTTP/2
Host: phamphutai.com
Accept: text/html
Accept-Encoding: gzip, br
```
The first word is the **method**. `GET` means "give me this," `HEAD` asks for headers only, `POST` sends data.
The response starts with a **status code**:
| Code | Meaning | You'll see it when |
|---|---|---|
| **200** | OK | The page is returned |
| **301** | Moved permanently | `www.` or `http://` gets redirected |
| **304** | Not modified | Your cached copy is still good |
| **404** | Not found | A typo in the URL |
| **5xx** | Server error | Something behind the edge broke |
Then come **headers**, the metadata. A few that matter for speed:
- **`content-type`** says what the body is: `text/html`, `text/css`, `image/png`. The browser trusts this, not the file extension.
- **`cache-control`** says who may cache the response and for how long. This site uses two very different rules. HTML pages get `public, max-age=0, must-revalidate`: the browser may keep a copy, but must check it's still current before using it, so a new post shows up immediately. CSS and JavaScript files under `/_astro/` get `public, max-age=31536000, immutable`: keep it for a year and never ask again. That's safe because Astro puts a hash of the content in the file name, like `Base.CL4LZlOo.css`. Change the file, and the name changes.
- **`etag`** is a fingerprint of the file. Next time, the browser sends it back in an `If-None-Match` header. If nothing changed, the server replies **304** with no body, and the browser uses its copy.
- **`content-encoding`** says how the body was compressed. Text compresses very well. This site's home page is 26,774 bytes raw and 5,173 bytes with **Brotli** (`br`), a compression format designed for the web. That's about **80% smaller**.
---
## Step 6: The browser turns bytes into pixels
Now the browser has HTML. The sequence of steps from there to a visible page is called the **critical rendering path**:
1. **Parse HTML into the DOM.** The **DOM** (Document Object Model) is a tree of every element on the page. The parser works as bytes arrive; it doesn't wait for the whole file.
2. **Parse CSS into the CSSOM.** The CSS Object Model holds every style rule. CSS is **render-blocking**: the browser won't paint until it has the stylesheets in the ``, otherwise you'd see a flash of unstyled page.
3. **Build the render tree.** Combine the DOM and CSSOM, keeping only what's visible. An element with `display: none` is dropped.
4. **Layout.** Work out the exact size and position of every box for this screen width.
5. **Paint.** Fill in the pixels: text, colours, borders, images.
6. **Composite.** Combine painted layers in the right order and show them on screen.
**JavaScript** can interrupt all this. A plain `