# Anatomy of a URL Request: How a webpage loads in under a second

You type `https://www.google.com` and hit Enter. The page loads in under a second. Simple, right?

Behind that single keystroke, **at least 12 distinct systems** spring into action — involving your browser, your operating system, your router, internet service providers, multiple DNS servers across the globe, physical fibre cables under the Indian Ocean, web servers in data centres, and encryption protocols protecting every byte.

Let's walk through all of it, step by step.

* * *

## Step 1 — You Press Enter: What the Browser Does First

The very first thing your browser does is **not** go to the internet. It checks its own memory. There are **five cache layers** it inspects, from fastest to slowest, before making any network call:

1.  **Browser memory (RAM) cache** — Pages and assets from this session. Instant. Cleared when you close the tab.
    
2.  **Browser disk cache** — CSS, images, JS saved on your hard drive. Survives browser restarts. Controlled by `Cache-Control` headers.
    
3.  **Service worker cache** — Used by Progressive Web Apps (PWAs) to serve content even offline. Think of how some apps still work without data.
    
4.  **OS DNS cache** — Your laptop or phone remembers recent DNS lookups. Lives in RAM. Survives browser restarts but clears on reboot.
    
5.  **Router DNS cache** — Your home Wi-Fi router also caches DNS. Shared by every device on the network.
    

Before any of this, the browser also **parses the URL** — breaking it into components:

```plaintext
https://www.google.com/search?q=nairobi+weather
│       │              │       │
Protocol Host/Domain   Path    Query string
```

If you typed just `google.com` without the protocol, the browser checks its **HSTS (HTTP Strict Transport Security) preload list** — a built-in list of sites that *must* use HTTPS. Google is on this list, so the browser automatically upgrades to `https://` before doing anything else.

> 🇰🇪 **Analogy:** This is like a matatu conductor who checks his own pocket notebook before asking the depot for directions. He starts local (his own memory), then checks his notes (disk cache), then calls a colleague (router), before finally asking the main office (ISP DNS). Most regular routes, he already knows by heart.

* * *

## Step 2 — DNS Resolution: The Internet's Phone Book

If all caches miss, the browser needs to find the **IP address** for `google.com`. Computers communicate using IP addresses — numbers like `142.250.185.46`. Humans use domain names. **DNS (Domain Name System)** is the translation layer between the two.

This translation happens through a chain of four server types:

```plaintext
Your Browser → Recursive Resolver → Root Server → TLD Server → Authoritative DNS → IP Address
```

### The Recursive Resolver

Your first stop is the **recursive resolver** — a DNS server run by your ISP (e.g., Safaricom, Zuku, Airtel Kenya) or a public alternative like Google (`8.8.8.8`) or Cloudflare (`1.1.1.1`). This server does the legwork on your behalf — querying other servers, caching the answer, and returning it to you.

### The Root Name Servers

If the resolver doesn't have the answer cached, it starts from the very top. There are **13 root server clusters** (named A through M) distributed worldwide — but despite being called 13, they have hundreds of physical machines using *anycast* routing, so your request automatically goes to the nearest one.

Root servers don't know Google's IP address. They know who does — they return the address of the **TLD server** for `.com`.

### The TLD (Top-Level Domain) Server

The TLD server knows all domains ending in `.com`. For Kenya's `.co.ke` domains, **KENIC (Kenya Network Information Centre)** manages the TLD server. The TLD server returns the address of Google's own **authoritative name server**.

### The Authoritative Name Server

This is the final, definitive answer. Google manages authoritative name servers for `google.com`. When queried, it returns the actual **A record** (IPv4) or **AAAA record** (IPv6). This answer comes with a **TTL (Time To Live)** — a timer in seconds telling resolvers how long to cache it before asking again.

Here are the key DNS record types you'll encounter:

| Record | Purpose |
| --- | --- |
| `A` | Maps domain to IPv4 address |
| `AAAA` | Maps domain to IPv6 address |
| `CNAME` | Alias — points one domain to another |
| `MX` | Mail server for the domain |
| `TXT` | Text data (SPF, DKIM, domain verification) |
| `NS` | Authoritative name server for the domain |

> 🇰🇪 **Analogy:**DNS is like asking for directions. You ask the *boda boda* guy (your ISP resolver). He doesn't know, but takes you to Nyamakima stage (root server). Nyamakima says "that area is along Moi Avenue" (TLD server). Moi Avenue gives you the specific building number (authoritative server). The whole journey takes 20–100ms — less than a blink.

> ⚡ **Performance fact:** Once your resolver caches the answer, subsequent DNS lookups for `google.com` take ~0ms — it answers from memory. This is why sites load faster after your first visit.

* * *

## Step 3 — TCP/IP: The Data Transport Layer

Now your browser has Google's IP address and needs to establish a **connection**. The internet transports data using two fundamental protocols:

*   **IP (Internet Protocol)** — handles addressing and routing. Defines how packets are addressed and directed across the network. Think of it as the envelope's address.
    
*   **TCP (Transmission Control Protocol)** — handles reliability. Ensures all data arrives, in the right order, without corruption. It breaks data into packets, numbers them, waits for acknowledgement, and retransmits anything lost.
    

### How Data Travels as Packets

Your request doesn't travel as one big blob. It's broken into **small packets** — typically 1,500 bytes each. Each packet travels independently, possibly via different routes, and is reassembled at the destination.

Each TCP/IP packet contains:

*   **Source IP** — your IP address (e.g., a Safaricom IP like `41.90.64.22`)
    
*   **Destination IP** — Google's server (`142.250.185.46`)
    
*   **Source port** — a random high port (e.g., `54231`) — your browser's "return address"
    
*   **Destination port** — `443` for HTTPS, `80` for HTTP
    
*   **Sequence number** — used to reassemble packets in order
    
*   **Payload** — the actual data
    
*   **Checksum** — for error detection
    

### The TCP Three-Way Handshake

Before sending any data, TCP requires both sides to confirm they're ready:

```plaintext
Browser → Server:  SYN      "I want to connect. My sequence  starts at 1000."
Server  → Browser: SYN-ACK  "Got it. My sequence starts at 5000. Yours acknowledged."
Browser → Server:  ACK      "Acknowledged your 5000. We're connected."
```

Connection is now **ESTABLISHED**. Data can flow in both directions.

> 🇰🇪 **Analogy:** TCP handshake is exactly like calling someone. "Unasikia?" (SYN) → "Naskia, unasikia?" (SYN-ACK) → "Naskia, tuendelee." (ACK). Both sides confirm the line is clear before the real conversation begins.

> 📡 **TCP vs UDP:** TCP guarantees delivery and order — it retransmits lost packets. **UDP** sends packets without checking if they arrived. UDP is used for video calls, live streaming, and gaming where a dropped frame is better than a 2-second retransmission delay.

* * *

## Step 4 — TLS Handshake: Encryption Negotiation

The TCP connection is just an open pipe — not secure. Anyone intercepting packets on the network can read them in plain text. The **TLS (Transport Layer Security)** handshake wraps that pipe in encryption. This is the "S" in HTTPS.

TLS 1.3 (the current standard) completes in **one round trip**. Here's what happens:

1.  **ClientHello** — Browser sends: TLS version, a random number, and a list of supported cipher suites (encryption algorithms it can use).
    
2.  **ServerHello + Certificate** — Server picks a cipher suite, sends its TLS certificate (containing its public key, signed by a Certificate Authority), and its own random number.
    
3.  **Certificate verification** — Browser verifies the certificate was signed by a trusted CA (like DigiCert or Let's Encrypt). Checks it hasn't expired. Generates a pre-master secret and encrypts it with the server's public key.
    
4.  **Session key derived** — Server decrypts the pre-master secret with its private key. Both sides now independently derive the same **symmetric session key**. Encrypted communication begins.
    

After the handshake, all data uses a **symmetric session key** — much faster than asymmetric encryption. The key is derived fresh for every session — this is called **Perfect Forward Secrecy**. Even if the server's private key is stolen later, past sessions cannot be decrypted.

> 🇰🇪 **Analogy:** TLS is like two people at a public matatu stage who switch to speaking Sheng so eavesdroppers can't follow. They agree on the "language" (cipher suite), and then only they understand what's being said.

> **Key insight:** Every HTTPS connection involves proving identity, agreeing on a secret, and speaking in a code only the two parties can break — all in under 50 milliseconds.

* * *

## Step 5 — The HTTP Request

The TCP connection is open. TLS encryption is active. Now your browser sends the actual **HTTP request** — the message asking for the page.

```plaintext
GET /search?q=nairobi+weather HTTP/1.1
Host:             www.google.com
User-Agent:       Mozilla/5.0 (Chrome/120 on Windows)
Accept:           text/html,application/xhtml+xml
Accept-Language:  en-US,sw;q=0.9
Accept-Encoding:  gzip, deflate, br
Connection:       keep-alive
Cookie:           SID=abc123; CONSENT=YES
Cache-Control:    max-age=0
```

Every HTTP request has a **method** telling the server what action to perform:

| Method | Meaning | Real-world use |
| --- | --- | --- |
| `GET` | Retrieve data | Loading a webpage, checking M-Pesa balance |
| `POST` | Send data to create | Submitting a form, placing an order on Jumia |
| `PUT` | Replace existing data | Updating your full profile |
| `PATCH` | Update part of data | Changing just your phone number |
| `DELETE` | Remove data | Deleting a message or account |

**Headers** carry metadata — the browser tells the server what language it speaks (`Accept-Language`), what formats it can handle (`Accept-Encoding`), who it is (`User-Agent`), and its authentication cookies.

* * *

## Step 6 — The Request Travels the Network

Your encrypted HTTP request is now a stream of TCP packets. They leave your device via Wi-Fi, travel through Safaricom's network, potentially cross the **TEAMS undersea cable** connecting East Africa to Europe, and eventually arrive at a Google data centre.

Along the way, every **router** the packet passes through does one job: look at the destination IP and decide the best next hop. This is called **IP routing**. The global routing table — maintained by thousands of routers using **BGP (Border Gateway Protocol)** — ensures packets always take an efficient path.

### CDN — The Shortcut

Large sites like Google, Netflix, and Facebook deploy **CDN (Content Delivery Network)** servers at dozens of locations globally — including Nairobi at **KIXP (Kenya Internet Exchange Point)**. If the content is cached at the Nairobi CDN node, your packet never leaves Kenya.

Instead of travelling 14,000km to a US data centre and back (~150ms latency), it travels a few kilometres and returns in under 5ms. This is why YouTube loads fast even on Safaricom 4G.

At Google's data centre, a **load balancer** sits at the front — distributing incoming requests across hundreds of backend servers so no single machine is overwhelmed.

* * *

## Step 7 — The Server Processes the Request

The request arrives at a Google server. Here's the typical processing chain for a dynamic request:

1.  **Web server (Nginx/Apache)** — Receives the HTTP request. Handles static files (CSS, images) directly from disk. For dynamic requests, forwards to the application server.
    
2.  **Application server** — Runs the actual code (Python, Java, Go, Node.js). Parses the request, applies business logic (is the user logged in? what results match?).
    
3.  **Cache layer (Redis/Memcached)** — Before hitting the database, checks if the result is already in fast in-memory cache. A cache hit returns in ~0.1ms.
    
4.  **Database (MySQL/PostgreSQL/Bigtable)** — Fetches persistent data. A typical DB query takes 1–20ms. Google uses Bigtable and Spanner — distributed databases replicating data across data centres for resilience.
    
5.  **Response assembled** — App server builds the HTML, sets response headers, and hands it to the web server to send back.
    

* * *

## Step 8 — The HTTP Response

The server sends back an HTTP response with a **status line**, **headers**, and a **body**:

```plaintext
HTTP/1.1 200 OK
Content-Type:     text/html; charset=UTF-8
Content-Encoding: gzip
Cache-Control:    private, max-age=0
Set-Cookie:       SID=xyz789; Secure; HttpOnly
Content-Length:   45231

<html>...</html>
```

### HTTP Status Codes — The Server's Way of Talking

| Code | Meaning | Nairobi analogy |
| --- | --- | --- |
| `200 OK` | Everything worked | "Karibu, kiti iko" |
| `201 Created` | Resource created successfully | "Order yako imepokewa" |
| `301 Moved Permanently` | Page has a new URL | "Tumehamia ofisi mpya" |
| `304 Not Modified` | Use your cached version | "Bado ni hiyo hiyo" |
| `400 Bad Request` | Your request is malformed | "Sijakuelewa" |
| `401 Unauthorized` | You need to log in | "Wristband kwanza" |
| `403 Forbidden` | Logged in, but no permission | "Wristband yako si ya VIP" |
| `404 Not Found` | Page doesn't exist | "Hiyo stage haipo" |
| `429 Too Many Requests` | You're being rate-limited | "Pumzika kidogo" |
| `500 Internal Server Error` | Server-side crash | "Jiko imeungua kitchen" |
| `503 Service Unavailable` | Server overloaded or down | "Tunarudi baadaye" |

* * *

## Step 9 — The Browser Renders the Page

The browser has the HTML. Now it turns that text file into the visual page you see. This is a multi-stage pipeline:

### 1\. HTML Parsing → DOM Tree

Browser reads HTML top-to-bottom, building a **Document Object Model (DOM)** — a tree of every element. `<html>` is the root, with `<body>`, `<div>`, `<p>` etc. as nodes.

### 2\. CSS Parsing → CSSOM Tree

CSS files are downloaded and parsed into a **CSS Object Model (CSSOM)** — which styles apply to which elements. This happens in parallel with HTML parsing.

### 3\. DOM + CSSOM → Render Tree

The two trees combine. Invisible elements (`display: none`) are excluded. The render tree contains only visible nodes with their computed styles.

### 4\. Layout (Reflow)

Browser calculates the exact size and position of every element. "This div is 400px wide, starts at x:120, y:340." CPU-intensive for complex pages.

### 5\. Paint

Browser converts each element to actual pixels — colours, borders, shadows, text. Done in layers, handled by the GPU.

### 6\. Composite → Display

Layers are combined and displayed on screen. JavaScript events are now active. The page is **interactive**.

> ⚠️ **The render-blocking problem:** When the browser encounters a `<script>` tag without `async` or `defer`, it stops everything — pauses HTML parsing, downloads the script, executes it, then resumes. A large JS file at the top of a page can delay first paint by seconds. This is why good developers put scripts at the bottom of `<body>` or use `defer`.

* * *

## The Full Journey — Everything in Under One Second

| Step | What happens | Typical time |
| --- | --- | --- |
| Cache check | Browser checks 5 cache layers | 0–5ms |
| DNS lookup | Recursive → Root → TLD → Authoritative → IP | 20–120ms |
| TCP handshake | SYN → SYN-ACK → ACK | 30–150ms |
| TLS handshake | Cipher negotiated, session key derived | 30–150ms |
| HTTP request sent | Browser sends GET with headers | <1ms |
| Network transit | Packets routed across ISP → cable → data centre | 20–300ms |
| Server processing | Web server → App → Cache/DB → response built | 1–200ms |
| Response transit | HTML travels back through network | 20–300ms |
| Browser rendering | DOM → CSSOM → Layout → Paint → Display | 50–500ms |

For a well-optimised site close to its CDN, the total time from Enter to first pixel is **under 200ms**. Across continents without a CDN, it can stretch to 1–2 seconds. The goal of every web performance engineer is to squeeze milliseconds out of every single step in that chain.

> 🇰🇪 **Analogy:** The whole process is like ordering nyama choma at a busy Nairobi joint. You walk in (TCP handshake). You show your ID at the door (TLS). You tell the waiter your order (HTTP request). He checks if there's ready food on the counter (cache). If not, the order goes to the kitchen (app server) who may need to go get fresh meat (database). The meal comes back to you (HTTP response). You eat (browser renders). The whole thing is done before your Tusker gets warm.

* * *