How to read a website waterfall chart

A page-load waterfall is the most honest picture of why a page is slow. Here's how to read one in about five minutes — with an example you can step through.

Step through an annotated waterfall

Start at the top: the HTML

Row 1 is always the document. Its green wait segment (310 ms) is server think-time plus a round trip — the TTFB. Nothing else can start until the browser has some HTML to parse.

  • DNS
  • Connect
  • TLS
  • Wait (TTFB)
  • Download
Request
0250 ms500 ms750 ms1.00 s1.25 s1.50 s1.75 s
  1. 487 ms
  2. 152 ms
  3. 206 ms
  4. 361 ms
  5. 333 ms
  6. 207 ms
  7. 508 ms
  8. 184 ms
  9. 86 ms
  10. 154 ms
  11. 526 ms

Hover or drag across the timeline to drop the finish line; tap a row for its full timing breakdown.

Highlighted rows for this step: www.example-shop.com.

The five phases of a request

  1. DNS lookup — resolving the hostname. Cached after the first request to a host.
  2. Initial connection (TCP) — one round trip to open the socket.
  3. TLS / SSL — agreeing on encryption keys; one round trip on TLS 1.3, two on TLS 1.2. Visualised here.
  4. Waiting (TTFB) — request sent, server working, first byte on its way back.
  5. Content download — the body arriving; proportional to size and bandwidth.

DevTools adds Queueing and Stalled before these: time the request waited for the browser to schedule it or for a free connection.

Five patterns to look for

  • A long first row. A slow document TTFB delays everything. Fix the server or cache first.
  • Staircases. Each request starting only when the previous ends means a dependency chain: CSS → @import → font, or JS → JSON → image. Flatten with preload or by inlining.
  • Many new connections. Lots of teal/amber/purple segments = many origins. Each costs 3+ round trips on a cold visit.
  • Idle gaps. White space on the critical path means the main thread was busy (parsing, executing) rather than the network.
  • One giant blue bar. An oversized image, video or JS bundle. Check it in the page size checker.

Vertical lines

Waterfalls mark page milestones with vertical lines: DOMContentLoaded (HTML parsed and deferred scripts run), Load (all initial resources done), and in WebPageTest also Start Render and LCP. In LoadTime's charts, the dashed Render unblocked line marks when the last blocking file finished, and the orange finish line is yours to drag.

Ready to try it on a real page? Run the page speed test or open a recording in the HAR analyzer.

Questions developers ask

What is a waterfall chart in web performance?

A horizontal timeline with one row per network request. Each bar starts when the request started and is split into phases — DNS, connect, TLS, waiting and download — so you can see what ran in parallel, what waited on what, and where the time went. The name comes from the cascading shape the bars make.

Where can I see a waterfall for my site?

Chrome, Edge, Firefox and Safari DevTools all have one in the Network panel. LoadTime draws one from a server-side test on the home page, or from a HAR file you export from DevTools. WebPageTest also produces detailed waterfalls from real browsers.

What does a gap between bars mean?

Time when the browser had nothing to download — usually because it was parsing HTML, executing JavaScript, or waiting for one file before it could discover the next. Gaps on the critical path are worth investigating because the network sat idle.

Is this the same as a financial waterfall chart?

No. A financial waterfall chart (in Excel or Google Sheets) shows how positive and negative values add up to a total. A page-load waterfall is a timeline of network requests; they only share the cascading look.