The HTTP request lifecycle you should actually understand

When you type a URL and press Enter, what happens? Most web developers have a rough idea. Fewer understand it well enough to diagnose performance problems or explain why things are slow.

Here's the actual sequence.

DNS Resolution

harbour.space → what's the IP?
→ Check browser DNS cache
→ Check OS DNS cache
→ Ask the recursive resolver (your ISP or 1.1.1.1)
→ Recursive resolver asks the root nameserver
→ Root nameserver delegates to .space nameserver
→ .space nameserver delegates to harbour.space's nameserver
→ harbour.space's nameserver returns: 123.45.67.89

This can take 20-120ms for an uncached domain. Subsequent visits are fast because the result is cached at every level.

TCP Handshake

Three packets: SYN, SYN-ACK, ACK. One round trip before any data moves. At 50ms round-trip time, that's 50ms of pure waiting.

TLS Negotiation

For HTTPS (which is everything now), an additional 1-2 round trips to negotiate encryption. TLS session resumption reduces this for returning visitors.

HTTP Request/Response

Only after all of the above does your HTTP GET request hit the server. The server processes it, queries the database, renders the template, and sends back the response.

What This Means in Practice

First load of a resource is expensive. DNS + TCP + TLS + HTTP request = multiple round trips before you see anything.

CDNs help dramatically. A CDN puts a server 10ms away instead of 150ms. That halves every round-trip cost.

Connection reuse matters. HTTP/2 multiplexes multiple requests over one TCP connection. HTTP/1.1 needed multiple connections for parallel requests.

When you open the browser devtools Network tab and see 'TTFB' (Time to First Byte), you're seeing the sum of everything above. Know what's in that number.