How it works · Capstone
Type a URL, press enter. By the time the page is on screen, half a dozen protocols and a dozen pieces of infrastructure have done their part. This page walks every phase, and points back at the guide that picks it apart.
Parts01 – 08 InteractiveCold / warm waterfall Cross-linksDNS · TCP · HTTPS · HTTP · LB
A page load is not one event. It is seven distinct phases, each with its own physics and its own bottleneck. Knowing them by name is the difference between "the site is slow" and "DNS is taking 200 ms because the resolver is in Frankfurt and the user is in Sydney."
The numbers below are realistic warm-path values for a fast residential connection to a major site. Cold-path adds a DNS hop, a TCP handshake, and a TLS handshake — typically 100–200 ms of preamble before the request even reaches the server.
Render is the largest single bucket on most pages. The first six phases combined often clock in under 200 ms. The seventh — what the browser has to do with the bytes — runs to seconds when the page is heavy. The cheapest performance optimisation is to send less.
Below: the same request, end-to-end. Toggle Cold vs Warm to see what connection reuse, DNS cache, and TLS resumption actually save you. Click a phase to jump; press Play to scrub.
protocol
network
0108216324432 ms
now: 0.0 ms of 432 ms
Phase 01 of 09 · Keyboard → browser 4.0 ms · cold · HTTP/2 · Fiber
Before the network ever sees this request, the input has to walk a small operating-system stack. The keypress fires a hardware interrupt, the kernel routes it to the focused window, the browser's render process decodes it, an IPC message wakes the network process. On a warm browser this is a few milliseconds; on a cold-launch it is hundreds. Most timelines start at "URL parse" and skip this entirely — but it is the place latency budgets are most often spent without anyone noticing.
# Phase 0 — what happens before the URL is "parsed" 1. Keyboard scan-matrix encoder fires (<1 ms) 2. USB/Bluetooth HID interrupt → kernel 3. OS kernel routes to focused process (the browser) 4. Browser event loop wakes, decodes Enter 5. Render-process IPC → network process 6. The network process now begins URL parsing # why it matters # this is "free" only when the user already # has a browser tab open. cold-start a browser # from a desktop click and it costs 200–800 ms # before a single packet has even been considered.
The browser knows the hostname; it needs an IP. Three layers of cache stand between the browser and the recursive resolver: an in-process cache, the OS resolver cache, and finally the recursive (1.1.1.1, 8.8.8.8, ISP). On a warm cache, this phase is half a millisecond. On a miss, the recursive walks root → TLD → authoritative and the latency depends on how close it is to those servers.
The full mechanics — including anycast, glue records, and the message wire format — live in the DNS guide. The point here is that this is one of the easiest phases to optimise: pre-resolve hostnames you will need, use a DNS provider with low p99 latency, and pay attention to TTL.
A new TCP connection costs one round trip — SYN, SYN-ACK, ACK, the protocol defined in RFC 9293. The full breakdown, including initial sequence numbers and the window options that ride along, lives in the TCP guide. What matters here is connection reuse.
Browsers maintain a per-origin connection pool. HTTP/1.1 keep-alive, HTTP/2 multiplexing, and HTTP/3 connection migration all exist to avoid paying this cost more than once. If the page loads ten resources from the same origin, only the first pays for TCP setup. The other nine ride the open connection.
TLS 1.3 brings up encryption in one round trip. With session resumption, the browser can encrypt the GET with a key derived from a previous session and send it alongside the ClientHello — zero-RTT, the handshake and the request fly together.
The mechanics, including PKI, certificate transparency, and what changed from 1.2 to 1.3, live in the HTTPS guide. What the timeline cares about: this used to cost two round trips, and now it can cost zero.
The request reaches a CDN edge first. If the response is in the edge cache, the answer comes back from there and the rest of the trip is short — see the CDN guide. If not, the edge forwards to the origin.
At the origin, a load balancer picks an app instance, often after a reverse proxy has already terminated TLS. The load-balancing guide covers algorithm choice — round robin vs P2C, L4 vs L7, what to measure. The chosen instance opens database connections, runs queries (often a fan-out of several), maybe calls a downstream service or two, then renders a response.
This is the phase where most production p99 lives. Database queries on cold caches. Network calls between services. Hot keys hashing to one shard. Single slow nodes that poison the pool. If a page is mysteriously slow, this is where the answer almost always is — the caching and Redis guides cover the fixes.
Bytes home. Now the browser parses HTML into a DOM, parses CSS into a CSSOM, combines them into a render tree, lays it out in real geometry, paints each layer, and composites on the GPU. Critical milestones along the way:
FCP
The first text or image appears. Usually arrives shortly after the HTML response because the browser can render before all stylesheets and scripts are loaded — unless render-blocking resources stop it.
LCP
The hero element — main image or headline — appears. Google's Web Vitals scores LCP because it correlates strongly with perceived load. Target ≤ 2.5 s on 75% of visits.
TBT / CLS
TBT measures long JavaScript tasks blocking the main thread. CLS measures whether the page jumps around as resources load. Both are about feel — they describe what the user notices.
Most pages spend the majority of their wall-clock time in two phases: phase 06 (the server hop) and phase 07 (the render). Optimisation budget should follow the time — you cannot squeeze a noticeable win out of TLS 1.3 because there is barely any time there to find.
Server side
Edge caching for everything that can be public. App-tier cache for everything that can't. Indexed, narrow database queries — the indexing guide is the right starting place. N+1 queries, hot keys, slow downstream calls — find the actual offender via tracing, not guesses.
Client side
Compression (gzip → Brotli → Zstd), code-splitting, lazy-loading images and scripts below the fold, deferring non-critical JS. The cheapest win is shipping fewer bytes. The next is making sure the bytes you do ship aren't blocking the first paint.
Read the waterfall first
Chrome DevTools Performance and the Network panel both show the phases above for any real load. Read the waterfall before you change anything. The biggest bar is the right thing to attack; everything else is wishful thinking.
Pick an answer for each. The right one reveals a short explanation; the wrong ones do too. There is no scoring — these are here so you can confirm the mental model travels with you when you go back to the editor.
Q1. A user has the page open and clicks an internal link. Which phases are skipped?
Q2. On a fiber link with 10 ms RTT, the cold-path TCP+TLS hit roughly equals…
Q3. Which phase typically dominates real-world page-load latency?
A closing note
This page is a capstone. Every phase here is one of the bespoke guides — TCP, HTTPS, DNS, HTTP, Load Balancing, CDN, Caching — all visible in their context. The goal of the Toolkit's how-it-works shelf is to make the entire stack legible. If you read this waterfall and know which guide each phase points at, you have a complete picture of the modern web request. Everything else is an alias for one of these phases.
Phase 02 · 9 min
DNS, how names resolve
Recursive resolution, root/TLD/authoritative tiers, message wire format, anycast, caching.
Phase 03 · 12 min
TCP, picked apart
Three-way handshake, sequence numbers, sliding window, congestion control, four-way teardown.
Phase 04 · 14 min
HTTPS, picked apart
TLS handshake, PKI, forward secrecy, ALPN/SNI, OCSP/HSTS/CT, what TLS 1.3 stripped.
Phase 05 · 11 min
HTTP, the shape of it
Request/response, headers worth knowing, HTTP/1.1 vs 2 vs 3, why head-of-line blocking matters.
Phase 06 · 11 min
Load balancing, picked apart
L4 vs L7, four algorithms compared, health checks, drain, GSLB, retry amplification.
Phase 06 · 7 min
CDN anatomy
PoPs, anycast, cache keys, origin shielding — where the edge cuts your latency in half.
Phase 06 · 9 min
HTTP caching
The four cache tiers (browser / CDN / app / DB), strategies, invalidation, stampedes.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。