How to Read a Network Waterfall for Web Performance Diagnosis

A network waterfall shows when each resource was requested, how long the browser waited, and when the response finished loading. But the most useful question is not simply “Which request is biggest?”

The useful question is: Where in the request path did the delay occur, and what should you investigate next?

A waterfall is diagnostic evidence. It can reveal late request starts, long waits for the first response byte, slow transfers, dependency chains and third-party activity. It cannot, by itself, prove why JavaScript execution is expensive or why rendering remains blocked after network activity completes.

What a Network Waterfall Actually Shows

A network waterfall is a timeline of browser requests.

The horizontal axis represents time.

Each row represents a request made while the page loads or runs.

Depending on the request, the browser may spend time:

• waiting before the request can be sent;
• resolving a hostname;
• establishing a connection;
• sending the request;
• waiting for the first response byte;
• downloading the response body.

Use it as part of a broader root-cause performance investigation.

Start With the Document Request

The document request is the first reference point for most page-load investigations.

Find the main HTML request and ask:

If the document spends a long time in Waiting (TTFB), every parser-discovered resource starts from a later baseline.

If the document responds quickly but a critical image or stylesheet begins much later, the investigation shifts toward discovery or dependency timing.

Understand the Timing Stages of a Request

Chrome DevTools can show a timing breakdown for individual requests. Not every request displays every phase because connection reuse, cache state, Service Workers and protocol behavior can change the request path.

Queueing and stalled time

Queueing occurs before connection start when the browser delays a request—for example because higher-priority requests exist, connection availability is constrained, or other browser scheduling conditions apply.

Stalled can occur after connection start for similar scheduling or connection-related reasons.

Do not convert a long queueing value directly into a root-cause conclusion. First ask whether the request is critical and what else is competing for resources.

DNS, connection and TLS

A request to a new origin may require work before HTTP data can flow.

Relevant phases can include:

• DNS Lookup — resolving the hostname;
• Initial connection — establishing the connection, including connection handshake behavior and SSL negotiation;
• proxy negotiation where relevant.

If an existing connection can be reused, some of these stages may not appear again.

Request sent

This is the period in which the request is being sent.

For typical page resources, this is often small compared with waiting or content download, but request payloads and connection conditions can change that.

Waiting for the response

Chrome labels this phase Waiting (TTFB).

The browser is waiting for the first byte of the response.

This timing can reflect both round-trip latency and the time required for the server or upstream path to prepare the response.

For WordPress-specific server-response diagnosis, see diagnose high WordPress TTFB.

Content download

Content Download is the time spent receiving the response body.

A long download can point toward several directions:

• large transfer size;
• limited throughput;
• slow network conditions;
• origin or CDN delivery constraints;
• the browser being busy enough to delay reading the response.

Do not assume that file size alone explains the duration.

Request Start Time Matters as Much as Duration

A small, fast resource can still hurt user-visible performance if it starts too late.

This is especially important for critical assets such as:

• LCP images;
• critical stylesheets;
• fonts required for visible text;
• scripts or data needed before important UI can appear.

For each critical request, inspect both:

This is the bridge between waterfall analysis and late LCP discovery.

How to Spot Late Resource Discovery

Ask:

Compare the request start time with the document timeline.

Possible discovery paths include:

• HTML → image;
• HTML → stylesheet → background image;
• HTML → JavaScript → component → image;
• HTML → JavaScript → API → UI resource;
• HTML → tag manager → third-party resource.

The waterfall can show that a request begins late.

It usually cannot, by itself, explain exactly why that request began at that moment.

That is where the initiator becomes important.

Use the Request Initiator to Understand Why a Request Started Late

The Network panel’s request initiator information helps explain what caused a request.

Chrome can identify initiators such as:

• the HTML parser;
• a redirect;
• JavaScript;
• other browser or navigation activity.

The Initiator tab can also expose a request initiator chain.

When a critical request starts late, inspect the initiator before assuming the resource itself is the problem.

How to Read Resource Dependency Chains

Resources often depend on earlier resources or application work.

For example:

Every dependency can move a user-visible critical request later in the timeline.

Chrome DevTools can show initiators and dependencies for a request, which helps reveal these relationships.

Do not assume every dependency chain is inherently bad.

The important question is whether it delays something that matters to the user-visible critical path.

Parallel vs Serial Loading

Waterfalls make request overlap visible.

Parallel loading

Multiple requests overlap in time.

Serial loading

One request starts only after another request or dependency reaches a certain point.

Serial behavior is not automatically a performance problem.

It becomes important when the serialized dependency controls:

• critical content;
• LCP resource discovery;
• rendering;
• important user-facing UI.

How to Find the LCP Resource in a Waterfall

Start by identifying the LCP element.

If that LCP candidate uses a network resource, find the corresponding request in the waterfall.

Then inspect:

• request start time;
• initiator;
• waiting time;
• content download duration;
• completion time.

This helps answer whether the LCP problem is associated with:

• document response;
• late discovery;
• slow resource transfer;
• or something that happens after the network resource is already available.

For the full routing framework, see diagnose slow LCP.

Pattern 1: High Document TTFB

Pattern:

This tells you that the response path deserves investigation.

It does not prove:

• the hosting is bad;
• PHP is slow;
• the database is slow;
• the CDN is misconfigured.

Those are hypotheses that require additional evidence.

Pattern 2: Critical Resource Starts Too Late

Pattern:

This points toward discovery, dependency or scheduling.

The next steps are typically:

1. inspect the request start time;
2. inspect the initiator;
3. inspect the dependency chain;
4. determine whether the resource is on the user-visible critical path.

For LCP-specific cases, see late LCP discovery.

Pattern 3: Resource Downloads Too Slowly

Pattern:

Possible investigation directions include:

• resource transfer size;
• compression;
• connection throughput;
• origin or CDN delivery;
• responsive resource selection;
• network conditions.

This is a transfer problem hypothesis—not an automatic image-format recommendation.

Pattern 4: Third-Party Requests Dominate the Network

Third-party activity can be visible as:

• many external domains;
• requests initiated by tags or scripts;
• late dependency chains;
• overlapping analytics, advertising, chat or embedded-media requests.

The waterfall can show network cost and request relationships.

It does not show the full CPU execution cost of third-party JavaScript.

When the Waterfall Looks Fine but the Page Is Still Slow

Sometimes the important requests appear to complete quickly, but the page still feels slow.

Possible directions include:

• long JavaScript tasks;
• style calculation;
• layout;
• rendering work;
• client-side execution;
• interaction processing.

This is the point where a waterfall has reached its limit.

Use a Performance Trace and consider the network vs CPU bottleneck distinction.

Network Cost vs CPU Cost

Cache Signals Change the Waterfall

A request may come from:

• memory cache;
• disk cache;
• a Service Worker;
• CDN or edge cache;
• the network or origin.

Different cache states can produce very different waterfalls.

A repeat visit with warm browser cache should not be treated as equivalent to a first visit with cold cache.

First Load vs Repeat Load

Always establish which state you are observing.

First load may include:

• connection setup;
• DNS;
• cold browser cache;
• first-time third-party requests;
• uncached resource transfer.

Repeat load may reuse:

• connections;
• browser cache;
• Service Worker responses;
• other cached resources.

Use a defined performance baseline so comparisons remain meaningful.

Mobile vs Desktop Waterfalls Can Differ

Desktop waterfall behavior does not automatically represent mobile.

Differences can come from:

• network profile;
• device behavior;
• responsive images;
• conditional resources;
• script behavior;
• different viewport-driven application paths.

When mobile experience is the issue, reproduce and inspect the relevant mobile condition rather than relying on a desktop-only waterfall.

Use Filtering and Sorting to Answer a Question

The Network panel lets you filter resource types such as:

• document;
• CSS;
• JavaScript;
• images;
• fonts;
• Fetch/XHR.

You can also inspect specific domains or sort the waterfall by start time, response time, end time, total duration or latency.

Examples:

• Which image requests start latest?
• Which requests spend the longest time waiting?
• Which third-party domain creates the most request activity?
• Which resources finish after the user-visible critical content should already have appeared?

Diagnostic Questions to Ask When Reading a Waterfall

Waterfall Pattern → Meaning → Limitation → Next Step

Request Stage → Diagnostic Meaning → Next Question

A Practical Waterfall Diagnostic Decision Tree

IS THE DOCUMENT RESPONSE LATE?
│
├─ YES
│  └─ Investigate TTFB → cache → origin → server / application
│
└─ NO
   ↓
DOES A CRITICAL RESOURCE START LATE?
│
├─ YES
│  └─ Check discovery → initiator → dependency chain
│
└─ NO
   ↓
DOES THE RESOURCE TAKE LONG TO DOWNLOAD?
│
├─ YES
│  └─ Investigate transfer size → network → CDN → throughput
│
└─ NO
   ↓
IS THE PAGE STILL SLOW AFTER RESOURCES COMPLETE?
│
├─ YES
│  └─ Use Performance Trace → CPU → main thread → rendering
│
└─ NO
   └─ Continue dependency / critical-path analysis

Common Network Waterfall Reading Mistakes

What a Network Waterfall Cannot Tell You

A waterfall is powerful, but its scope is limited.

It does not fully explain:

If the network looks healthy but the page remains slow, continue with a Performance Trace.

If the document response is slow, continue with server or application evidence.

If a request begins late, continue with initiator and dependency evidence.

What Evidence Should You Inspect Next?

• Request Initiator
• Performance Trace
• Network vs CPU Bottleneck
• Diagnose Slow LCP
• Late LCP Discovery
• Identify the LCP Element
• Diagnose High WordPress TTFB
• Performance Baseline
• Verify a Performance Change
• Performance Investigation

Final Takeaway

Start with:

• the document request;
• critical request start time;
• Waiting (TTFB);
• Content Download;
• the request initiator;
• dependency relationships.

Then determine whether the bottleneck is:

• network;
• delivery;
• resource discovery;
• or somewhere outside the network entirely.

A waterfall is evidence. Root-cause diagnosis requires the next layer of proof.