How to Audit Your Website's Request Waterfall

The request waterfall is the most information-dense view in web performance analysis. It shows every network request your page makes — HTML, CSS, JavaScript, images, fonts, APIs — laid out on a timeline. Understanding it turns a vague “my site is slow” into “this specific JavaScript file is blocking paint for 1.2 seconds.”

Reading the Waterfall

Each row in the waterfall represents one resource. The horizontal bar shows its timeline, broken into phases:

DNS Lookup — Resolving the domain to an IP. Only happens on the first request to each domain. Should be under 50ms.

TCP Connection — Establishing the TCP connection, including TLS handshake. Again, only the first request per domain. HTTP/2 reuses connections.

Waiting (TTFB) — How long the browser waited for the first byte of the response. This is where server processing time shows up.

Content Download — How long it took to download the response. Proportional to file size divided by available bandwidth.

The Critical Rendering Path

Not all requests are equal. The critical rendering path includes everything the browser needs to render the initial view:

1. HTML document (TTFB)
2. CSS files in <head> (render-blocking)
3. JavaScript in <head> without defer/async (render-blocking)
4. Any resources referenced in those CSS/JS files

These form a chain. If your CSS file loads a font file, that font file’s load time adds to the critical path.

What to Look For

Render-blocking chains

Look for requests that start at the same time the HTML finishes loading, but block the “Start Render” marker (usually shown as a vertical line). These are your render-blocking resources.

Wide gaps between requests

A gap before a request starts usually means the browser was blocked by a previous request. This is the waterfall “staircase” effect — requests that could load in parallel are loading sequentially because of dependencies.

Slow TTFB on the main document

If the first bar (the HTML document) has a long yellow “Waiting” section, that’s server processing time. Everything else is delayed by this.

Large files

Sort by file size. The largest files take longest to download. Are those large files actually needed on this page?

Too many requests

More requests means more TCP connections, more DNS lookups, more round-trips. HTTP/2 multiplexing helps, but there’s still overhead per request. Third-party tracking scripts, social buttons, and analytics often add 5–20 requests.

Late-discovered resources

Images and fonts that appear at the bottom of the waterfall and start loading long after the page has rendered are late-discovered. These can cause layout shifts (CLS) or delayed LCP if the browser didn’t know about them from the initial HTML.

Common Patterns and Fixes

Long TTFB on the HTML document → Add server-side caching, use a CDN, optimize database queries.

CSS and JS blocking render → Use defer on scripts, inline critical CSS, preload key assets.

Font files loading late → Add <link rel="preload" as="font"> in the <head>.

Many requests to the same third-party domain → Self-host critical scripts. Eliminate unnecessary third-party scripts.

Images loading after DOMContentLoaded → Add explicit width/height attributes. Use fetchpriority="high" for the LCP image.

Large uncompressed responses → Verify Content-Encoding: gzip or Content-Encoding: br headers on text-based assets.

Using the Waterfall on debugutils.dev

Every speed test on debugutils.dev includes a full request waterfall with resource types color-coded:

• Red — HTML
• Yellow — JavaScript
• Blue — CSS
• Green — Fonts
• Purple — Images

You can see file sizes, TTFB, download time, and initiator for every request. The filmstrip runs in parallel above the waterfall so you can correlate visual changes with specific requests.

This is the view that professional developers use to diagnose real performance issues — not just scores. For a deeper dive into reading waterfall patterns, see Reading a Request Waterfall.