Redirect Waterfall - Which Hop Owns the Wait

## Why it matters

A chain's total wait never splits evenly. One distant server or a slow DNS lookup can own 200ms of a 300ms total, which makes collapsing that hop worth fixing or switching CDNs worth testing. A waterfall shows you which hop to target first instead of guessing, and it backs up your case to stakeholders with hard numbers they can see.

It also separates real latency from noise. A hop that takes 5ms is fine; a hop that takes 150ms is the problem. The waterfall makes that obvious.

## How it works

The waterfall visualises time. The horizontal axis is milliseconds. The first bar (the first request) starts at time zero. Each bar's width is how long that hop took from when the request left the browser until the response arrived.

Each subsequent bar starts where the previous one ended. That's when the browser sent the next request. So if hop 1 took 80ms and finished at 80ms, and hop 2 took 120ms, the waterfall shows one bar from 0–80 and another from 80–200.

The total wait is the end of the last bar. If you collapse a 3-hop chain into 1, and the 2-hop difference saves 80ms, the waterfall shows that savings visually: a shorter rightmost bar.

A cached hop takes near-zero time because nothing touched the network. The waterfall shows it as a thin line; it registers in the total duration but adds almost nothing to the wait.

## What does not matter

The waterfall is not a server trace. It's wall-clock time observed in the browser, not a detailed breakdown of what the origin was doing. You see how long the browser waited, not whether the server was busy or whether the network was congested. For that, you'd need server-side telemetry or a detailed RUM tool.

The timing is also per hop, not per component. If hop 1 included a DNS lookup, a TLS handshake, and the actual HTTP request, those are combined into one duration. The Network panel in DevTools breaks them out further, but the extension's waterfall is simpler: how long each full round trip took.

## Code example

Here's what the waterfall data looks like in a HAR file:

{
  "entries": [
    {
      "startedDateTime": "2024-01-15T10:30:00.000Z",
      "request": { "url": "http://example.com/old" },
      "response": { "status": 301 },
      "timings": {
        "wait": 45,
        "receive": 2
      }
    },
    {
      "startedDateTime": "2024-01-15T10:30:00.047Z",
      "request": { "url": "https://www.example.com/new" },
      "response": { "status": 200 },
      "timings": {
        "wait": 120,
        "receive": 50
      }
    }
  ]
}
Copy

The first hop started at time 0, took 47ms total (45ms wait + 2ms receive). The second hop started 47ms later, took 170ms total (120ms wait + 50ms receive). Total: 217ms from first request to final response.

The waterfall visualises this as two bars: the first spanning 0–47ms, the second spanning 47–217ms.

## How Scalpel Redirects shows it

The redirect popup shows a "Timing waterfall" section under the chain. Each hop is a bar, placed left-to-right by when it completed, sized by its duration in milliseconds. The total duration is printed at the end. If you hover a bar, it highlights and shows the exact timing for that hop.

When you're deciding whether to collapse a chain, the waterfall tells you what you'll save. A 3-hop chain taking 300ms total, with one hop taking 150ms, means collapsing could cut it by half. That's the pitch to your stakeholders: hard numbers, not "redirects are bad."