Typing a URL and getting a page back feels trivial.
Under the hood, it’s a tightly timed sequence across DNS, transport, TLS, and application layers - and small inefficiencies anywhere show up as “this site feels slow”.
Here’s the clean version of the flow.
1) Name Resolution (DNS)
Your client needs an IP for the hostname.
- Stub resolver -> recursive resolver (often ISP, or public like Cloudflare / Google)
- Cache hit? Return immediately.
- Cache miss? Walk the walk: root -> TLD -> authoritative
- Respect TTLs, possibly DNSSEC validation
Latency cost: typically 5-40ms with a warm cache, more on cold paths.
Gotchas:
- High RTT to resolver
- Poor cache hit rates
- Misconfigured TTLs causing excess lookups
2) Transport Setup (TCP or QUIC)
TCP (HTTP/1.1, HTTP/2)
3-way handshake:
- SYN -> SYN-ACK -> ACK
Cost: 1 RTT before data.
QUIC (HTTP/3)
Runs over UDP, combines transport + crypto setup.
Cost: 0-1 RTT depending on session resumption.
Why it matters: Fewer round trips = faster TTFB, especially on high-latency paths.
3) TLS Negotiation
For HTTPS, you’re doing TLS (usually 1.3 now):
- Cipher suite negotiation
- Key exchange (ECDHE)
- Certificate validation
- Session resumption if available
Cost: ~1 RTT (less with resumption/QUIC)
Gotchas:
- Large cert chains
- OCSP/CRL delays (if not stapled)
- No session reuse
4) HTTP Request / Response
Now we actually ask for /.
- Headers go out (cookies, UA, etc.)
- Server responds (status, headers, body)
With HTTP/2:
- Multiplexed streams over one connection
- Header compression (HPACK)
With HTTP/3:
- Similar semantics, better under packet loss
TTFB depends on:
- Server processing time
- Upstream dependencies (DB, APIs)
- Network RTT
5) Rendering Pipeline (Client-Side)
Browser:
- Parses HTML -> builds DOM
- Fetches subresources (CSS, JS, fonts, images)
- Builds CSSOM
- Executes JS (which can block rendering)
- Layout + paint
This is where a “fast server” can still feel slow.
Common issues:
- Render-blocking JS/CSS
- Too many round trips for assets
- No prioritisation
6) Edge Caching / CDN
Most production setups sit behind a CDN like Cloudflare.
- Anycast routes you to a nearby POP
- Cached assets served at the edge
- Origin only hit on miss
Benefits:
- Lower RTT
- Offload origin
- Better resilience
Where Performance Is Actually Won/Lost
If you’re optimising, these are the levers that matter:
- RTT (physical + routing path)
- Handshake overhead (TCP + TLS vs QUIC)
- Cache hit ratio (DNS + CDN)
- Connection reuse (keep-alive, H2 multiplexing)
- Payload efficiency (compression, fewer requests)
Bandwidth matters far less than people think once you’re past a certain point.
Why This Matters (In Practice)
When someone says “the internet is slow”, it’s usually one of:
- Resolver latency or DNS issues
- High RTT / poor routing
- Packet loss impacting retransmissions
- TLS / handshake overhead on fresh connections
- Origin slowness or bad frontend design
Not “my line speed is too low”.
Takeaway
Loading a site is a pipeline of dependent steps:
DNS -> transport -> TLS -> request -> render
You don’t feel the individual pieces - you feel the sum.
And the difference between a “snappy” site and a sluggish one is usually just a few extra round trips in the wrong places.
