Network Waterfall Reading

Read request waterfalls: critical path chains, priority, blocking, and how to shorten discovery delays.

beginner3 min readUpdated Aug 4, 2026

performance
waterfall
network
lcp
devtools

A network waterfall charts each request’s start and duration over time. Reading it well separates “server is slow,” “we discovered the hero too late,” and “we serialized three JS files for no reason.”

Docs: Chrome Network waterfall, Optimize LCP, Resource Timing.

Anatomy of a bar

|queue|dns|connect|ssl|ttfb|download|

Long waiting → TTFB. Long download → bytes/bandwidth. Late start → discovery or priority.

Patterns and fixes

1. Long chain of JS

index.html → app.js → route.js → chart.js → data.json

Each waits on previous discovery. Fix: route-level split with preload of next chunk, data in initial HTML/SSR, fewer serial dynamic imports.

2. Late LCP image

Image starts after huge JS. Fix: <img> or preload in initial HTML with fetchpriority="high" — LCP tactics.

3. CSS blocks everything

Render-blocking CSS spans until download completes. Fix: reduce CSS, split by route — critical CSS.

4. Connection storms to many hosts

Many DNS/TLS gaps. Fix: fewer origins, selective preconnect — preconnect.

5. Healthy H2 parallelism

Many bars start near-simultaneously on one connection — good. Don’t force artificial sequencing.

Priority column

Browsers deprioritize lazy images and some async scripts. Mis-tagged LCP as lazy shows low priority + late start. Check Priority in Network panel.

Correlate with Performance panel

Network track above main thread: script download finishes → long Evaluate Script → late LCP marker. That is render delay, not only network.

Building RUM waterfalls

Use Resource Timing entries sorted by startTime for field approximations — remember cross-origin limits without Timing-Allow-Origin.

Interview out-loud

“I read waterfalls for late starts vs long TTFB vs long downloads. Serial JS chains and late-discovered LCP resources are frontend discovery bugs; long TTFB is origin/CDN. Priority and protocol columns complete the story.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.