diagnostic · one of 36 The kept baseline - this load held against a saved one - is Pro; the waterfall and both exports are free.
Requests
What did this page load, and which request failed or dragged?
The browser records every request this page made whether or not anybody was watching, and that buffer is the reading: what was asked for, when, what came back and how long each phase took, drawn on one time axis. Opening the tool after the load loses nothing the buffer still holds - nothing is re-fetched, and a request the page made before the panel existed is a row like any other.
Reach it Press ⌘ + K on any tab and type requests. Ctrl + K on Windows and Linux
in the panel · this one is Pro
What this actually is
every request on one time axis, with status, size and phasesA page that loads slowly and nobody has established what it loaded, an API call somebody swears fires and nobody can see, or a 404 that only shows up as a missing icon. Also the handover: a row copies as a cURL line and the whole reading exports as HAR, which is the shape a backend developer or a bug tracker actually wants.
Asked about this diagnostic
4 of themWhy do some rows show a zero size and no phases?
Because a cross-origin response that does not opt in with Timing-Allow-Origin withholds its transfer size and its phase timings, and the browser hands back zeroes. Those rows are named as withheld rather than drawn as instant and weightless, which is what the zeroes would otherwise read as.
Does running it make any requests of its own?
No. The buffer is a record the browser keeps regardless, and this reads it. Nothing is re-fetched, nothing is probed, and the reading transmits nothing - the HAR file is assembled locally from the same record.
How is this different from Page weight?
Same buffer, different grain. Page weight sums it by kind and answers what the page cost; this keeps every request separate and answers what happened - which request, in what order, with what status, taking how long in which phase.
Why does the list stop at 250 requests?
That is the buffer's default depth, and past it the browser drops the oldest entries. The reading says so when it happens rather than presenting a truncated record as the whole story - a page that made four hundred requests has a different problem than its slowest one.
how to use requests
- Open Requests. The browser's buffer already holds the load, so nothing is re-fetched.
- Read the time axis: what was asked for, when, what came back, and how long each phase took.
- Find the failure or the drag, then export that row as cURL.
- Past 250 entries the record is partial, and the tool says so rather than implying it is complete.
70 of these · no host permissions · three free audits