What Is a Network Request? Reading the Waterfall to Debug Faster

The word covers any fetch the browser makes: an HTML document, a CSS or JS file, an image, a font, an XHR or fetch() call to an API. Each one carries a method (GET, POST), a URL, request and response headers, a status code, and a body. The DevTools Network panel records all of them and draws the waterfall: requests stacked by start time, with the lighter part of each bar showing time spent waiting and the darker part showing time spent downloading bytes.

A single bar in the waterfall is not one number — it is a stack of labeled phases, and reading which phase is widest is the whole skill. Chrome DevTools' Timing tab breaks one request into as many as ten phases: Queueing, Stalled, DNS Lookup, Initial connection, Proxy negotiation, Request sent, ServiceWorker preparation, Request to ServiceWorker, Waiting (TTFB), and Content Download. So the waterfall is one row per phase, not one opaque bar. A request that looks slow is often a request that never got on the wire.

That is where the most common misdiagnosis hides. A request can sit in Queueing or Stalled purely because, in Chrome's own words, 'there are already six TCP connections open for this origin, which is the limit' under HTTP/1.0 and HTTP/1.1. The server is idle; the browser simply has no free connection slot, so the seventh request waits its turn. Blame the backend here and you will tune a server that was never the problem. The fix is protocol, not code: HTTP/2 and HTTP/3 multiplex many requests over one connection and drop the six-per-origin cap entirely.

The front half of the bar gets misread too. MDN defines TTFB as the gap from requesting a page to the first byte of the response, and that single number 'includes DNS lookup and establishing the connection using a TCP handshake and TLS handshake if the request is made over HTTPS.' A high TTFB can therefore be network setup, not backend work. Total load time then adds Content Download on top, so a fast TTFB with a slow total just means the payload is large. Read the band that dominates before you assign blame.

The waterfall has a machine-readable twin, and that twin is the reason this glossary entry matters beyond an open DevTools tab. The PerformanceResourceTiming API exposes the same timeline as numbers: domainLookupStart, connectStart, requestStart, and responseStart. TTFB becomes responseStart - requestStart; DNS time becomes domainLookupEnd - domainLookupStart. One catch — cross-origin entries return 0 for those detailed fields unless the server sends a Timing-Allow-Origin header, so third-party timings are opaque by default.

This is not a niche concern. In the 2024 Web Almanac, 15% of all requests were still served over HTTP/1.1 against 85% on HTTP/2, which means the six-connections-per-origin queueing rule still governs roughly one request in seven on the web. And a slow request is not only a backend issue: Google's 'good' INP threshold is 200 ms at the 75th percentile, and an XHR or fetch() that blocks an interaction's paint counts against it. A network request is a Core Web Vitals input, not just a number in a panel.

Every tutorial above treats the waterfall as a live tuning exercise inside an open DevTools tab. The problem is that bugs do not happen while you are watching. By the time a teammate files 'cart is empty after checkout,' the failing request scrolled out of the Network panel hours ago, on a machine you do not have. The live waterfall is gone. What you need is the same timeline frozen at the moment of failure and attached to the report — and that is exactly the structured shape PerformanceResourceTiming already gives you.

That is the wedge BugMojo is built on. The browser extension captures the failure with its surrounding context — an rrweb session replay, the console output, and the network requests with their timings, statuses, and payloads. So the report does not say 'something failed'; it carries the actual POST /api/cart that returned 500, its TTFB, and its response body, sitting next to the replay frame where the cart rendered empty. The waterfall becomes a forensic artifact rather than a screenshot someone forgot to take.

Then the BugMojo MCP server hands that bundle to an AI agent — Claude Code, Cursor — as structured data. Because the request is fields, not pixels, the agent correlates 'the 500 on POST /api/cart' with 'the empty-cart render in this replay' on its own. It reads the status, the timing, and the body the way it reads a stack trace, and reasons about cause without a human ever opening DevTools. A captured, agent-readable waterfall does what a live, human-only one cannot.