How to read a waterfall chart

A speed score is a summary. A waterfall chart is the evidence underneath it — every single request the page made, listed in the order it happened, with a bar showing exactly how long each one took and what it spent that time doing. Reading it properly is the difference between guessing at a fix and actually knowing what to fix.

Every major speed testing tool produces one, and so does the network panel in your browser's own developer tools. The layout differs slightly between tools, but the underlying idea is the same everywhere.

What you are looking at

Each row is one request — an HTML document, an image, a stylesheet, a script, a font. Reading left to right along a row shows you when that request started relative to the start of the page load, and how long it took. Rows are usually shown roughly in the order requests were made, which is why the overall shape often looks like a cascading staircase — hence "waterfall".

Most tools colour-code these segments, so a long, brightly coloured "waiting" segment stands out as a slow server response, while a long "content download" segment points instead at a large file taking time to transfer once the server has already answered.

What to actually look for

The first bar

The very first request is the HTML document itself, and its "waiting" segment is your server response time — see what TTFB actually measures. Nothing else on the page can begin until this request has returned at least some of the document, so a long first bar delays everything drawn beneath it as well, not just itself.

Gaps between requests

A visible gap where nothing appears to be happening usually means the browser was busy processing something — parsing a large stylesheet, or executing a script — before it could discover and request whatever comes next. This is one of the clearest signs of a render-blocking resource: something the browser has decided it must deal with before it can carry on.

Anything unusually wide

A single bar that is dramatically longer than everything around it is almost always worth investigating first, because it is often the single largest contributor to total load time on the page. This is commonly an oversized image, an unminified script, or a third-party resource loading from a slow or distant server outside your own hosting entirely.

Requests that start late

If an important resource — particularly the image that becomes your Largest Contentful Paint element — does not start loading until well into the waterfall, something is delaying the browser from discovering it early. This is often a resource referenced only inside a stylesheet or a script, rather than directly in the HTML, which means the browser has to fetch and parse something else first before it even learns the image exists.

A worked example

Say a page's waterfall shows: a long "waiting" segment on the very first HTML request, followed by several stylesheet and script requests loading one after another rather than in parallel, followed by a very wide bar for a hero image starting only after all of those have finished. That single chart tells you three separate things worth fixing: the server response itself is slow, something is preventing the browser from fetching multiple resources at once early on, and the hero image is both late to start and large once it does. Each of those has a different fix, and the chart is what told you all three existed rather than leaving you to guess at one.

A method for reading any waterfall

1. Check the first bar's waiting segment

   This is your server response time, and it sets a floor under everything that follows.

2. Scan for the widest bars

   These are usually the biggest single opportunities, whatever they turn out to be.

3. Look for gaps with nothing happening

   Often a sign of a script or stylesheet blocking the browser from moving on to the next request.

4. Note anything starting surprisingly late

   Particularly your largest visible image — a late start there usually means it needs preloading.

5. Fix the single largest issue, then re-test

   Re-run the test and pull a fresh waterfall rather than assuming the fix worked — the chart itself is the confirmation.

Once you can read a waterfall confidently, most of the other guides in this section become much faster to apply, because you can see exactly which one applies to your specific page rather than working through all of them in order. Start with running a proper speed test if you have not already, since that is what produces the chart in the first place.