How websites work

1. How a website gets to your screen

When you type a domain (e.g. google.com) and press Enter, a chain of steps fires before anything appears.

Step-by-step

Step	What happens
DNS cache check	Browser, OS, and router are checked for a saved IP address
DNS lookup	If no cache hit, a resolver tracks down the IP (see section 3)
TCP handshake	Browser and server exchange SYN → SYN-ACK → ACK to open a connection
TLS handshake	If HTTPS, encryption is negotiated on top of the TCP connection
HTTP request	Browser sends `GET /` with headers and any cookies
Server responds	Server sends back HTML and a status code (e.g. `200 OK`)
Parse + fetch more	Browser reads HTML, discovers CSS/JS/images, fires parallel requests
Render	Browser paints pixels to screen — you see the page

On a fast connection, this entire process takes under 1 second.

2. DNS cache

A DNS cache is a local memory of domain → IP lookups your device has already performed. Instead of running the full lookup chain every time, your device checks the cache first.

Where caches live (checked in this order)

Browser cache — Chrome, Firefox, and Safari each keep their own. Fastest to check.
Operating system cache — managed by mDNSResponder on Mac, DNS Client service on Windows.
Router cache — your home router caches lookups so all devices on the network benefit.
ISP resolver cache — your internet provider's resolver caches results shared across all its customers.

TTL (Time to Live)

Every DNS record has a TTL — a number (in seconds) set by the website owner that tells caches how long to keep the record before expiring it.

TTL of 300 = 5 minutes
TTL of 86400 = 24 hours
When TTL expires, the next request triggers a full fresh lookup

This is why when a website moves to a new server, it can take hours or a full day for everyone to see the change — caches are still holding the old IP.

Flushing the cache

If you have a stale (outdated) cache entry, you can clear it manually:

# macOS
sudo dscacheutil -flushcache

# Windows
ipconfig /flushdns

# Chrome
chrome://net-internals/#dns  →  "Clear host cache"

Security: DNS cache poisoning

An attacker can trick a cache into storing a wrong IP, routing you to a fake site. DNSSEC prevents this by cryptographically signing DNS records so resolvers can verify they're legitimate.

3. DNS lookup and the recursive resolver

When there's no cache hit, a full DNS lookup runs. Your device hands the problem to a recursive resolver, which does all the legwork.

The four players

Role	Who they are	What they know
Recursive resolver	Your ISP, or public resolvers like `8.8.8.8` (Google) / `1.1.1.1` (Cloudflare)	Nothing at first — but asks until it finds the answer
Root nameserver	13 IP clusters (A–M), hundreds of machines worldwide	Which server handles each TLD (`.com`, `.org`, etc.)
TLD nameserver	e.g. Verisign runs `.com`	Which authoritative nameserver is registered for a domain
Authoritative nameserver	Controlled by the domain owner (e.g. Google)	The actual IP address — the final answer

The lookup sequence

Your device
    │
    │  "What's the IP for google.com?"
    ▼
Recursive resolver
    │
    │  "Who handles .com?"
    ▼
Root nameserver  ──▶  "Ask the .com TLD nameserver"
    │
    │  "Who handles google.com?"
    ▼
TLD nameserver  ──▶  "Ask Google's authoritative nameserver"
    │
    │  "What's the IP for google.com?"
    ▼
Authoritative nameserver  ──▶  "142.250.80.46"
    │
    ▼
Resolver caches the answer, returns IP to your device

Why "recursive"?

The resolver keeps making requests on your behalf until it has a complete answer — rather than passing the work back to your device. Your device makes one request and waits; the resolver handles everything else.

Recursive = resolver does all the chasing (normal behaviour)
Iterative = your device would follow each referral itself (rare, mostly used between servers)

Timing

Situation	Time
Cache hit	< 1ms
Full recursive lookup	20–120ms

4. The three types of websites

The core difference between website types is where and when the HTML gets built.

Static sites

HTML files are pre-built before anyone visits. The server just hands out files — no logic runs on request.

Flow: Request → CDN/file server → returns pre-built HTML → browser renders
Speed: Very fast (files served straight from cache)
Best for: Blogs, portfolios, documentation, landing pages
Examples: GitHub Pages, any site built with Hugo or Jekyll

Dynamic sites

HTML is built on the server at request time, customised per user by pulling data from a database.

Flow: Request → app server → queries database → merges data into template → sends HTML → browser renders
Speed: Slower than static (server does real work per request)
Best for: Logged-in users, e-commerce, content that changes frequently
Examples: Amazon, Reddit, most news sites

Single-page apps (SPAs)

You load one HTML shell once, then JavaScript takes over. The page never fully reloads — only data is fetched from APIs as you interact.

Flow: Request → CDN → sends HTML shell + JS bundle → JS runs → API calls fetch data as JSON → JS updates the page in place
Speed: Slow initial load, then instant interactions (no full reloads)
Best for: Highly interactive apps where fluid UX matters more than initial load time
Examples: Gmail, Figma, Google Maps
Frameworks: React, Vue, Angular

Comparison

	Static	Dynamic	SPA
HTML built	At deploy time	Per request on server	In the browser at runtime
Server work per request	None	High	Low (just data)
Initial load speed	Fastest	Medium	Slower
Interactions after load	Full reload each time	Full reload each time	Instant, no reload
Good for SEO	Yes	Yes	Harder (improving)
Database needed	No	Yes	Yes (via API)

Note: Modern frameworks like Next.js blur these lines — you can mix all three approaches on a page-by-page basis within the same project.

Notes compiled from a conversation covering how the web works end-to-end.