When you type a URL, seven actors — browser, resolver, router, origin, CA, CDN edge, and render engine — execute twelve phases in sequence. This lesson maps the whole journey.
You type a URL and a page appears in under 400 ms. That gap is not magic — it is twelve distinct phases executed by seven actors who have never met each other and never will. Knowing which actor owns which phase is the foundation of every performance and debugging skill in this chapter.
The seven actors
Every HTTPS request passes through a cast of characters, each owning exactly one concern:
Bea (browser) — initiates the request, renders the result.
Rex (recursive DNS resolver) — translates the hostname to an IP address.
Rita (router network) — carries packets hop-by-hop across the internet.
Cara (certificate authority) — vouched for the server’s identity before the request ever started; her signature lives inside the server’s certificate.
Patty (CDN/proxy) — intercepts the connection at a nearby edge point of presence (PoP), serves cached content, or forwards to origin.
Sven (origin server) — computes the real response when no cache can answer.
Bea’s render engine — parses the HTML/CSS/JS and paints pixels.
Phase
Actor
What happens
Typical cost
1. DNS lookup
Rex
hostname → IP
<1 ms warm / 30–100 ms cold
2. TCP connect
Rita + Sven/Patty
3-way handshake
~10–100 ms (RTT)
3. TLS handshake
Bea + Sven + Cara
key exchange, cert verify
1 RTT new / 0 RTT resumed
4. Proxy / rate-limit check
Patty
health check, cache lookup, WAF
<1–5 ms
5. HTTP request
Bea → Sven
GET / with headers
~1 RTT
6. Origin processing
Sven
auth, DB query, serialise
10–200 ms
7. HTTP response
Sven → Bea
status + headers + body
~1 RTT + body size
8. Subresource fetches
Bea (parallel)
CSS, JS, fonts, images
1–3 RTT (parallelised)
9. DOM + CSSOM parse
Bea
build render tree
0–50 ms
10. Layout + paint
Bea
position elements, rasterise
50–200 ms
11. JavaScript execute
Bea
event handlers, hydration
0–500 ms
12. LCP painted
Bea
largest visible element ready
total: 200–4000 ms
Why the order is fixed
When you see a page take 800 ms and want to know where the time went, you need to know which actor owns which phase — otherwise you are optimizing the wrong thing. Each phase depends on the output of the previous one. DNS must resolve before Bea knows which IP to connect to. TCP must complete before TLS can exchange keys. TLS must complete before HTTP can send the encrypted request. This strict sequencing is why round-trip count, not round-trip speed, is the primary latency lever — you can shorten each RTT by moving the server closer, but you cannot skip the RTTs without redesigning the protocol.
The three network handshakes (DNS + TCP + TLS) are a fixed ~150 ms of round-trips before a single byte of HTML arrives — which is exactly the cost a CDN edge hit compresses by serving from 20 ms away.
The one exception: CDN edge caching short-circuits the chain. If Patty has the answer in cache, phases 4–7 collapse into a single CDN response. Bea still pays DNS + TCP + TLS (phases 1–3), but those happen against a server 20 ms away instead of a server 200 ms away. That is the chapter’s central performance insight in one sentence.
The delivery metaphor
Think of the request as a package delivery:
You place an order (HTTP request).
The address is looked up in a phone book (DNS).
A van is dispatched on a road network (TCP + Rita’s routing).
The parcel is sealed in tamper-evident wrap (TLS).
A local depot might have the item already stocked (CDN cache).
The parcel arrives at your door (response).
You unbox and use it (browser render).
Together, these seven steps explain why swapping the delivery truck for a faster one (bigger bandwidth) rarely fixes perceived slowness — you still pay for the phone book lookup, the road network, and the unsealing. Each role is independent; each can be measured and optimised separately.
▸Why this works
The strict layer dependency exists for a good reason: each layer can be optimised, replaced, or failed independently. DNS can be changed without touching TLS. TLS can be upgraded (1.2 → 1.3) without changing HTTP semantics. This is the separation of concerns principle applied to networking at planetary scale.
Quiz
Completed
In what order do the first four phases run for a fresh HTTPS request?
Heads-up Reverse — DNS happens first because the browser needs an IP before it can open any socket.
Heads-up TCP cannot run without an IP address, which comes from DNS first.
Heads-up They strictly depend on each other; parallelism only helps within a phase, not across phases.
Order the steps
Completed
Order the phases from keystroke to first paint:
1DNS resolves the hostname to an IP
2TCP three-way handshake
3TLS 1.3 handshake and certificate verify
4HTTP request sent
5HTTP response received
6Browser fetches subresources (CSS, JS, fonts) in parallel
7Browser lays out DOM and paints the first visible content
Complete the analogy
Completed
Fill in the blank: the network stack is a _______ where each layer wraps the one below it.
Answer
onion (or stack) — Each layer encapsulates the one below: HTTP inside TLS inside TCP inside IP inside Ethernet. The same byte travels through every wrapper on its way out.
1. DNS lookupRex: hostname → IP
2. TCP connectRita + Sven: 3-way handshake
3. TLS handshakeBea + Sven + Cara: keys + cert
4. Proxy / rate-limit checkPatty: cache, WAF
5. HTTP requestBea → Sven: GET /
6. Origin processingSven: auth, DB, serialise
7. HTTP responseSven → Bea: status + body
8. Subresource fetchesBea: CSS, JS, fonts
9. DOM + CSSOM parseBea: render tree
10. Layout + paintBea: position + rasterise
11. JavaScript executeBea: handlers, hydration
12. LCP paintedBea: largest element ready
Each phase depends on the output of the one above it, so they run strictly top to bottom. Round-trip count — not round-trip speed — is the primary latency lever, and a CDN edge cache hit collapses phases 4–7 into one nearby response.
Recall before you leave
01
Name the seven actors in an HTTPS request and one concern each owns.
02
Why can you not parallelise DNS, TCP, TLS, and HTTP?
03
What makes CDN edge caching the highest-leverage latency optimisation?
Recap
One URL triggers a twelve-phase chain executed by seven actors: Rex resolves the hostname, Rita’s routers carry packets, Bea negotiates TLS with Sven using Cara’s certificate, Patty may answer from cache, and Bea’s render engine paints the result. The phases are strictly ordered — each depends on the previous — so round-trip count, not round-trip speed, is the primary latency lever. A CDN edge hit at 20 ms instead of 200 ms shortens all three handshakes simultaneously. Now when you see a slow page load, your first question is: which actor owns the slow phase — and is the bottleneck the round-trip count or the round-trip time?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.