You type a URL, press Enter, and within about three hundred milliseconds, one third of a second, a full page appears. Magic? No. Engineering. Six small protocols, each doing one clear job, hand in hand. Today, kardeşim, we'll follow the click all the way from your keyboard to the first pixel. Every step runs in your own terminal; nothing is hidden.

The "cloud" is just other people's computers, after all, ma şaa Allah how far a little electricity can reach.

Step 0, the URL itself

Before anything travels, the browser parses the text you typed. The demo above shows the three parts that matter for most requests: 

https  ://  webstree.com  /blog
  ↑         ↑              ↑
scheme    host           path
  • scheme, which protocol to speak. https almost always; sometimes http, ws, mailto.
  • host, the name of the server. DNS will turn this into a number in a moment.
  • path, which page or resource on that server. The server decides what this means.

There are two more parts a URL can carry, query (?q=nuxt&page=2) and fragment (#intro). Query travels to the server; fragment stays in the browser. We'll keep things simple today.

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.

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 word on messages

Every GET is a short letter. Header, body, signature. Every tradition has known that a message carries responsibility, for its source, its accuracy, and its effect. The Qur'an calls a trusted communication an emanet; 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 really a 500; don't mislead a user's browser with a wrong Content-Type. A straight protocol respects the reader at the other end. That's the craft, kardeşim, and that's the adab.

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, bismillâh.