Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Chrome's Network waterfall is the single densest source of latency information available without touching the server. Every colour segment maps to a specific network phase: grey ('Queueing/Stalled') means the browser is waiting to open a socket — a sign of connection-pool exhaustion or HTTP/1.1 head-of-line blocking; teal ('Initial connection') is TCP; yellow ('DNS lookup') means the DNS cache expired; dark-green ('Waiting/TTFB') is server think-time; light-green ('Content download') is transfer time. Misreading these costs hours: engineers who see a long dark-green bar and blame the network are looking at server-side latency; engineers who see a long grey bar and tune the database have the wrong diagnosis entirely.
Chrome DevTools Network waterfall segments are color-coded by HTTP phase, but each color's meaning is not obvious until you connect it to the underlying protocol events. Stalled time maps to connection pool exhaustion or browser queuing; DNS lookup is the first orange segment; connection and SSL are distinct phases that vanish on keep-alive reuse. Learning to read the waterfall accurately lets you triage client-side performance issues without instrumenting the server at all.
Use these three in order. Each builds on the one before.
In one paragraph, explain what Chrome DevTools' Network waterfall shows and how to identify whether a slow request is a server-side problem vs a network problem.
Walk me through what HTTP/2 multiplexing does to the waterfall shape compared to HTTP/1.1 with six connections per host.
I see a page where 30 API calls all have a 600 ms 'Stalled' phase but < 20 ms 'Waiting (TTFB)'. The server responds quickly. What is causing the stalling and give me two concrete fixes.
# Waterfall colour → phase → what to investigate
# Grey — Queueing / Stalled
# Browser waiting to open a TCP connection.
# Cause A: HTTP/1.1 max 6 connections per host — requests queue behind in-flight ones.
# Cause B: Low-priority resource deferred by the scheduler.
# Fix: Use HTTP/2 (multiplexing eliminates the 6-conn limit).
# Yellow — DNS Lookup
# Name resolution for this host.
# If > 50 ms: check DNS TTL, consider a local resolver or DNS prefetching.
# Fix: <link rel="dns-prefetch" href="//api.example.com"> in HTML.
# Teal — Initial Connection
# TCP handshake (+ TLS if HTTPS).
# High if cross-region or cold connection.
# Fix: Connection keep-alive, HTTP/2, or move origin closer.
# Purple — SSL/TLS
# TLS handshake on top of TCP.
# High on first connection; near-zero on reuse (session resumption).
# Fix: TLS session tickets, HTTP/2.
# Dark green — Waiting (TTFB)
# Server think-time: from request sent to first response byte.
# THIS is where database, cache, and application code latency shows up.
# Fix: Database indexes, caching, query optimisation.
# Light green — Content Download
# Body transfer time.
# High if response body is large or bandwidth is limited.
# Fix: Compression (gzip/br), pagination, field selection.go run main.go