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:

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:

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:

🇰🇪 **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:

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.

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:

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:

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

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

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.