You type webstree.com, press Enter, and within about three hundred milliseconds — a third of a second — a full page appears. It looks like magic. It isn't. It's six simple steps, each with a clear job. Once you see them laid out, the web stops feeling mystical and starts feeling like plumbing. The demo at the top of this post is a scaled-down visualisation: one "packet" travelling from left to right, each station lighting up when it's that station's turn.

Let's follow your click all the way to the first pixel.

Step 1 — DNS: the phone book lookup

webstree.com is a name. Humans love names; routers love numbers. A server on the internet has an address like 91.134.23.87. The system that translates name → number is called DNS, the Domain Name System.

You can watch it happen in a terminal:

$ dig webstree.com +short
91.134.23.87

Behind the scenes: your computer asks a local DNS resolver → which asks a root server → then the .com server → then finally the server in charge of webstree.com. The answer gets cached at every hop, so your next visit is nearly instant. This step usually takes 10–50 ms.

Step 2 — TCP: "are you there?"

Now we know the address. Your computer opens a connection — three small packets exchanged before any real data flows:

  1. SYN — "hello, can we talk?"
  2. SYN-ACK — "yes, let's talk."
  3. ACK — "great, here we go."

This is the TCP handshake. It takes one round trip. Light is fast; distance is the real tax. 20–80 ms is typical. 

$ ping webstree.com
64 bytes from 91.134.23.87: time=42.3 ms

Step 3 — TLS: lock the conversation

The s in https:// stands for secure. Before anything sensitive travels, the two sides agree on a secret key nobody else can read. The server also hands over a certificate — a digital ID card signed by a trusted authority — and your browser verifies the chain.

Modern TLS 1.3 does this in one round trip.

$ openssl s_client -connect webstree.com:443 -servername webstree.com
CONNECTED(00000003)
depth=2 ...
subject=/CN=webstree.com
issuer=/CN=Let's Encrypt Authority X3
...

After this step, everything sent in either direction is encrypted. A café Wi-Fi snooper sees opaque bytes, not your password.

Step 4 — HTTP: "give me /blog"

Now the actual request. It's plain text:

GET /blog HTTP/1.1
Host: webstree.com
User-Agent: Mozilla/5.0 (...)
Accept: text/html
Accept-Encoding: gzip, br

Seven lines. The server replies in the same shape:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 18432
Cache-Control: public, max-age=3600

<!DOCTYPE html>
<html>...

Run the whole thing yourself with curl -v https://webstree.com/ — the -v flag prints every header. Do it once; you'll never be afraid of HTTP again.

Step 5 — Parse: read the map

The browser receives raw HTML and reads it top to bottom. Every time it finds a <link>, <script>, or <img>, it kicks off another request — back through DNS (cached now), TCP (reused now), HTTP — and the cycle repeats in parallel for each resource.

Meanwhile, the browser is building a DOM tree — an in-memory version of your HTML that JavaScript will later read and modify. It's just nested JavaScript objects, nothing mystical.

Step 6 — Render: painting pixels

Once enough HTML + CSS has arrived, the browser runs three stages:

  1. Layout — "where does each box go?" Reads CSS, computes geometry.
  2. Paint — "what color is each pixel?" Fills boxes with text, images, borders.
  3. Composite — "stack the layers and put them on the screen." GPU work.

The first pixel you see lands about 150–300 ms after you hit Enter — on a decent connection, with a well-built site. If it's slower, one of these six steps is misbehaving, and DevTools can tell you exactly which one.

See it with your own eyes

Open any page, press F12, go to the Network tab, tick Disable cache, and reload. You'll see the full waterfall — each bar is a single resource, the colored sub-segments are exactly the steps above:

  • green = DNS lookup
  • orange = Initial connection (TCP + TLS)
  • blue = Request sent
  • purple = Waiting (server processing)
  • pink = Content download

This is the whole web, visualised. Nothing hidden.

Tricks and shortcuts

  • Cache is king. Repeated visits skip steps 1–4 almost entirely thanks to DNS cache, TCP keep-alive, session resumption, and HTTP caching headers. That's why the second load feels so much faster.
  • CDNs cheat the speed of light. A CDN puts copies of your files in data centres near the user, so steps 1–4 travel a short distance instead of across an ocean.
  • HTTP/3 (QUIC) folds TCP + TLS into one step. If you see h3 in the protocol column of DevTools, you're on the modern stack.
  • A slow page has a slow step. Don't optimise blindly — look at the waterfall, identify the specific segment that's wide, fix that one thing.

A note on messages

Each GET and each response is, in essence, a short letter. Header, body, signature. Every tradition has known that a message carries responsibility — for its source, its accuracy, and its effect. HTTP is that same old thing, written in a machine's hand. When you build, build honest responses: don't pretend a 200 when it's a 500; don't lie about Content-Type to slip something past a user's browser. A straight protocol respects the reader on the other end.

Takeaways

  1. A URL is a name; DNS turns it into a number.
  2. TCP + TLS open a secure channel in 1–3 round trips.
  3. HTTP is plain text — requests and responses you can read by eye.
  4. The browser parses, fetches more, and renders in three stages.
  5. Every step is measurable. Every slowdown has a specific cause.

The web only looks like magic when you stand far from it. Step close, and it's six small protocols holding hands. Once you've seen the handshake, you'll never fear the load.

Next post: "CSS without frameworks — what Tailwind hides from you" — flexbox, grid, clamp(), :has(), and the four tools that quietly replace 90% of a utility framework.

Read the waterfall. Learn your pipes. Ship calmer code.