Understanding Web Page Load Times: A Detailed Breakdown
The response explains the breakdown of a web page's load time, including DNS, TCP, TLS, TTFB, and render-blocking resources, and discusses the waterfall reading order, the impact of connection speed, and the difference between compounding a
A read-only, creator-approved conversation screened before publication.
Trace where a typical web page's load time actually goes: DNS, TCP, TLS, TTFB, and render-blocking resources. Explain the waterfall reading order, what dominates on a fast vs slow connection, and which optimizations have compounding versus additive effects. Use one concrete example with realistic millisecond numbers.
A page load is a chain of serialized round trips. Here's the anatomy, the reading order, and where the time actually goes. THE WATERFALL, PHASE BY PHASE Each resource in the waterfall is one row, and each row has the same skeleton, left to right: 1. DNS lookup — resolve hostname to IP. One resolver round trip. 2. TCP connect — SYN/SYN-ACK/ACK. One network round trip. 3. TLS handshake (HTTPS only) — ClientHello through Finished. 1-2 round trips (1-RTT on TLS 1.3, 2 on 1.2). 4. TTFB (Wait) — request sent, server processes, first byte returns. One round trip plus server work. 5. Download — actual payload transfer, gated by bandwidth, not latency. 6. Render-blocking chain — the browser stops at blocking CSS/JS and fetches them serially before it can paint. READING ORDER Read top to bottom, left to right. The vertical lines are milestones: DOMContentLoaded, first paint, load. The critical path is the chain of rows that block rendering — usually the HTML, then its blocking CSS, then blocking JS. Gaps between bars are idle time where the browser is waiting on a dependency (e.g. it can't fetch the stylesheet until it finished parsing the <head>). The page's load time is the right edge of the LAST critical-path resource — not the sum of all bars, since non-blocking resources (images, async scripts, fonts) load in parallel and off the critical path. CONCRETE EXAMPLE — 4G mobile, RTT ~80ms, origin far from user DNS lookup 30ms TCP connect 80ms (1 RTT) TLS handshake 120ms (~1.5 RTT) TTFB (server processing) 250ms HTML parse 40ms Render-blocking CSS 80ms (1 RTT, serialized after HTML) Render-blocking JS 80ms (1 RTT, after CSS) First paint ~680ms total Now the same page on a fast connection — RTT 10ms, HTTP/2, CDN edge serving cached HTML: DNS (CDN, cached) 5ms TCP 10ms TLS 15ms TTFB 40ms (edge server, not origin) CSS 10ms JS 10ms First paint ~90ms total WHAT DOMINATES, BY CONNECTION Fast connection (low RTT, high bandwidth): the waterfall is flat and dominated by TTFB and by the NUMBER of round trips, not their size. Backend latency and the count of render-blocking resources are the whole story; bandwidth is irrelevant because payloads transfer in a fraction of an RTT. Slow connection (high RTT, low bandwidth): handshakes and serial fetches dominate. Every extra round trip costs you a full RTT, and large payloads now cost multiple RTTs to transfer. DNS/TCP/TLS together can exceed the TTFB. This is why mobile-first sites obsess over round-trip count, not just bytes. COMPOUNDING VS ADDITIVE Additive optimizations remove one cost once: - Minifying one file, removing one blocking script, caching one asset. Each saves exactly its own fetch time and nothing else. Compounding optimizations reduce a cost that every later step inherits: - Cutting RTT (CDN edge, HTTP/3, preconnect) shrinks every round trip downstream — DNS, TCP, TLS, and every resource fetch all get faster at once. One change, multiplied across the whole waterfall. - HTTP/2 multiplexing collapses N blocking fetches into one connection, turning a serial chain into a single round trip — the benefit multiplies with the number of resources it removes from the critical path. - Compression/caching that drops a payload below one RTT's transfer time converts a bandwidth cost into a latency cost, which then benefits from every latency optimization above. The compounding ones are the ones that matter: they attack the shape of the waterfall (round-trip count and RTT), while additive ones only shave individual bars. Rule of thumb: fix the number of round trips first, then the size of the payloads, then the server time — in that order, because each earlier fix makes the later ones cheaper.
[System: The previous response was cut off by a network error mid-stream. Continue exactly where you left off. Do not restart or repeat prior text. Finish the answer directly.]
That ordering is the practical takeaway: latency fixes compound across every bar in the waterfall, payload fixes compound only across the resources that share a round trip, and server-time fixes are strictly additive to the critical path. If you only ship two optimizations, make them a CDN edge (kills RTT everywhere) and HTTP/2 (kills the serial resource chain) — those two together typically take the 680ms example down to triple digits, while minification alone saves tens of milliseconds.
RELATED SIGNALS
Explanation of HTTPS Certificate Validation and Man-in-the-Middle Attacks
The response explains the end-to-end process of HTTPS certificate validation, including the chain of trust, intermediate certificates, OCSP
READ TRANSMISSION →
JavaScript Event Loop: Microtasks vs. Macrotasks
The response explains how JavaScript's event loop schedules microtasks and macrotasks, with a worked example showing the output order of set
READ TRANSMISSION →
Analysis of Password Persistence and Future Predictions
The response explains the persistence of passwords, discussing economic factors, the FIDO2/passkey model, the recovery problem, and the impa
READ TRANSMISSION →