Performance Monitoring

Network Waterfall Analysis: Understanding Your Load Chain

Analyze network waterfalls to identify bottlenecks in your page load chain. Learn to read waterfall charts and optimize critical resource loading paths.

AzMonitor TeamOctober 10, 20257 min read · 867 wordsUpdated January 20, 2026
network waterfallpage loadperformance analysisresource loading

The network waterfall chart is one of the most information-dense tools in web performance analysis. It shows every network request your page makes, when each request starts, how long each takes, and how requests depend on each other. Understanding how to read and act on waterfall data is a core skill for anyone serious about web performance.

Reading a Waterfall Chart

A waterfall chart shows time on the horizontal axis and individual requests on the vertical axis. Each row represents one request, and the bars within each row show the timing breakdown:

Request to yoursite.com:
│◄─DNS─►│◄TCP─►│◄TLS─►│◄─────TTFB──────►│◄─Download─►│

Where:
DNS    = Domain name lookup
TCP    = Connection establishment
TLS    = SSL/TLS handshake
TTFB   = Time to first byte (server processing + network)
Download = Response download time

Color coding in Chrome DevTools:

  • White/empty: Queued, waiting for a connection slot
  • Gray: Stalled (connection negotiation)
  • Dark orange: DNS lookup
  • Orange: Connecting (TCP)
  • Purple: SSL negotiation
  • Green: Waiting (TTFB)
  • Blue: Downloading

Identifying Common Waterfall Problems

Render-Blocking Resources

The most impactful waterfall problem: CSS and JavaScript files that block rendering. These appear at the top of the waterfall with nothing rendering after them until they complete:

Waterfall (problem):
├─ [HTML document] ─────────────────────────────────
│   └─ [render blocks until these complete]
├── [style.css]─────────────────────────
├── [app.js]────────────────────────────
│
└─ [First paint happens here, very late]

Fix: Add defer to JavaScript, load non-critical CSS asynchronously.

Long Chains of Sequential Requests

When Request B can't start until Request A completes, you have a request chain. This serializes loading time:

Problem waterfall:
├─ [HTML] ──────────────
│   └─ [blocking CSS] ──────────────
│         └─ [@import CSS] ──────────────
│               └─ [web font] ──────────────
│                     └─ [First paint]

Total: Sum of all sequential downloads

Fix: Preload critical resources, inline critical CSS, eliminate CSS @imports.

Too Many Concurrent Requests (HTTP/1.1)

HTTP/1.1 limits connections to 6 per origin. Many requests to the same origin queue and wait:

HTTP/1.1 problem:
├─ [Request 1] ─────────
├─ [Request 2] ─────────
├─ [Request 3] ─────────
├─ [Request 4] ─────────
├─ [Request 5] ─────────
├─ [Request 6] ─────────
│ 
├─ [Request 7: Queued] ─────────  ← Waits for slot
├─ [Request 8: Queued] ─────────

Fix: Enable HTTP/2 (multiplexes all requests on one connection), use resource hints, reduce number of requests.

Waterfall "Staircase" Pattern

A staircase pattern indicates sequential dependencies — each resource only starts loading after the previous one completes:

Staircase pattern:
[HTML]
      [discovered CSS]
                     [discovered font]
                                     [discovered image]

This is the critical path problem. Fix: Preload resources the browser would otherwise discover late.

The Critical Path: What's Between Start and Paint

The critical path consists of all resources the browser must load before it can paint meaningful content. Shortening the critical path is the highest-ROI performance optimization.

Identify your critical path:

  1. Open Chrome DevTools → Performance
  2. Record a page load
  3. Look at the timeline — when does "First Contentful Paint" fire?
  4. Work backward: what network requests completed just before FCP?

Minimize the critical path by:

  • Inlining truly critical CSS (< 14KB that styles above-the-fold content)
  • Preloading your LCP image
  • Deferring all non-critical JavaScript
  • Moving Google Fonts to self-hosted (eliminates a DNS lookup + connection)

Resource Hints for Waterfall Optimization

Resource hints tell the browser to take action on resources before it discovers them in the HTML:

<!-- preconnect: Establish connection early (DNS + TCP + TLS) -->
<link rel="preconnect" href="https://fonts.googleapis.com">

<!-- dns-prefetch: DNS lookup only (less aggressive than preconnect) -->
<link rel="dns-prefetch" href="https://cdn.your-analytics.com">

<!-- preload: Download resource immediately with high priority -->
<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
<link rel="preload" href="/hero.webp" as="image">

<!-- prefetch: Download for next navigation (low priority) -->
<link rel="prefetch" href="/about">

Overusing preload is a common mistake. Preloading too many resources competes for bandwidth with resources the browser already wants to prioritize. Preload only the 2-3 most critical resources.

Waterfall Analysis Tools

Chrome DevTools Network Panel

The built-in tool. Shows all requests with timing, headers, and response data. Right-click to "Save all as HAR" for sharing with colleagues.

WebPageTest

The most powerful waterfall analysis tool. WebPageTest shows:

  • Connection view (resources grouped by connection)
  • Request details with byte-by-byte timing
  • Filmstrip view showing visual progress alongside waterfall
  • Comparison between different locations/settings

WebPageTest's waterfall is the gold standard for detailed performance analysis.

Lighthouse

Lighthouse highlights waterfall-related issues in its audits:

  • "Eliminate render-blocking resources"
  • "Preconnect to required origins"
  • "Preload key requests"
  • "Avoid chaining critical requests"

Monitoring Waterfall Health Over Time

Individual waterfall analysis is valuable but manual. For continuous monitoring, track waterfall-derived metrics:

Request count: Alert if the number of requests increases significantly after a deployment.

Total transfer size: Alert if total page size exceeds budget.

Critical path length: Alert if critical path latency increases.

Number of third-party domains: Alert if new external domains appear (often from third-party scripts added by marketing).

AzMonitor's performance monitoring captures these metrics continuously, alerting when your page's loading chain degrades. Start waterfall health monitoring with AzMonitor and see your load chain from multiple global locations.

See also: website speed monitoring for the metrics that come out of waterfall analysis.

Tags:network waterfallpage loadperformance analysisresource loading
Back to blog
A
AzMonitor Team
The AzMonitor team writes guides based on experience monitoring millions of endpoints daily across 10,000+ customer environments. Our expertise covers uptime monitoring, SRE practices, and reliability engineering.
Try AzMonitor free

3 monitors free forever · No credit card needed · Set up in 2 minutes

Start monitoring free →