What the Resource Waterfall Analyzer does
This analyzer draws a waterfall from a HAR file - every request on one timeline, each bar split into queueing, DNS, TCP connect, TLS, send, wait and download - and then points out what is slowing the page: a slow first byte on the HTML, stylesheets and scripts that probably block rendering, requests stuck in the queue, too many new connections, failed requests and oversized responses.
The HAR is read in your browser tab and never uploaded, which matters because HAR files often contain cookies and authorisation headers. If you have no HAR, an optional mode times a public URL from the a2z.tools server; that gives server-measured fetch times and sizes, clearly labelled, not a browser waterfall.
How to use it
- In Chrome, Edge or Firefox open DevTools, go to the Network panel, tick Disable cache if you want a first-visit view, and reload the page.
- Export the recording as HAR (the download arrow in Chrome, or right-click > Save all as HAR) and drop the file here, or paste its JSON.
- Press Draw waterfall. Read the findings first; they name the requests worth looking at.
- Use the waterfall to see the shape of the load: long gaps, requests that start only after another finishes, and bars dominated by one colour. The dashed lines mark DOMContentLoaded and load.
- Sort the table by Wait, Queued or Size to find the worst offenders, and download the CSV to compare before and after a change.
Reading the results
Each bar starts when the request started and is split by HAR phase. Grey (queued/blocked) is time waiting for a connection or for the browser's priority scheduler; teal is DNS; amber is TCP connect with green TLS inside it; purple is wait - the server's time to first byte; blue is the download.
Long purple segments mean a slow server or API. Long grey segments early in the load mean the browser is juggling too many requests or has deprioritised them. Many amber/green segments mean many new connections - each new origin costs round trips before any byte flows.
"Likely render-blocking" lists stylesheets, and scripts the HTML itself requested, that started before DOMContentLoaded. A HAR cannot say whether a script was async or deferred, so treat the list as candidates to check in the HTML.
The phase totals add each phase across all requests. Because requests overlap, the sum is work, not elapsed time; it is useful for seeing which kind of delay dominates.
Worked example: a shop home page with a slow API call at the end
The sample HAR has 18 requests totalling about 1.1 MB. The HTML's timings are 2 ms queued, 28 ms DNS, 96 ms connect (58 ms of it TLS), 1 ms send, 612 ms wait and 38 ms download - 777 ms in all, with a slow 612 ms first byte.
Three product images each spend over 300 ms queued behind the 486 KB hero JPEG on the same CDN connection, and five requests - main.css, fonts.css and three scripts - are likely render-blocking before DOMContentLoaded at 1,180 ms.
The last response is /api/recommendations at 2,237 ms: it starts at 1,380 ms and waits 842 ms for the server. It is chained behind app.js and chunk-reviews.js, which is why it starts so late - the Critical Request Chain Visualizer shows that chain as a tree.
Formulas and scoring rules
- Request time (HAR 1.2)
time = blocked + dns + connect + send + wait + receivePhases of -1 do not apply and count as 0. ssl is already included in connect, so it is not added again.- Request end
end = start + max(time, sum of phases)When a HAR's time and phases disagree, the larger is drawn and a warning is shown.- Start offset
start = startedDateTime - earliest startedDateTimeMilliseconds from the first request.- New connection
a request with connect > 0 opened a connection; otherwise it reused one
What a HAR can and cannot tell you
A HAR records what one browser did on one load: its network, its cache state, its extensions. It is excellent for seeing the order and cost of requests and weak as a benchmark - reload twice and the numbers change. Record on a throttled connection (DevTools "Fast 4G" or "Slow 4G") to see the shape your mobile visitors get.
Chrome adds private fields such as _priority, _initiator and _transferSize; the analyzer uses them when present. Other browsers' HARs work without them, with less detail about who requested what.
Limitations: what the result does not prove
- A HAR is one load on one machine - lab data. It does not show your visitors' networks or devices, and it does not measure rendering, only the network.
- Render-blocking detection is a heuristic: a HAR does not record async or defer, so some listed scripts may not block.
- Files are limited to 50 MB and the first 5,000 requests; the chart draws the first 400 rows.
- The URL mode's timings come from the a2z.tools server fetching files one by one. They show server speed and file weight, not the order or overlap of a real page load.
Privacy: where your data goes
The analysis runs in your browser. If you choose to load a public URL instead of pasting, a2z.tools fetches that address read-only and returns the text to your tab; private and internal addresses are refused and nothing is stored. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- W3C HTTP Archive (HAR) format - checked 19 Sep 2026
- Chrome DevTools - Network features reference
- web.dev - Optimize Time to First Byte
Frequently asked questions
How do I export a HAR file from Chrome?
Open DevTools (F12), select the Network tab, reload the page so every request is captured, then click the download arrow in the Network toolbar (Export HAR). Chrome now strips cookies and auth headers by default unless you choose the sensitive-data option.
What does the blocked or queued phase mean?
It is time the request spent waiting before it could be sent - for a free connection, behind higher-priority requests, or while the browser allocated resources. Long queueing early in the load usually means too many requests competing at once.
Why is TLS drawn inside the connect bar?
The HAR 1.2 specification defines ssl as part of connect, so the connect figure already includes the TLS handshake. The waterfall shows the TLS share in its own colour inside the connect segment instead of adding it twice.
Is it safe to load a HAR that contains cookies?
The file is read by JavaScript in this tab and never sent to a2z.tools or anyone else. Even so, redact or regenerate sessions before sharing a HAR with other people, because it can contain login cookies and tokens.
What is a good time to first byte for the HTML?
web.dev's LCP guidance suggests TTFB should take about 40% of your LCP budget, which for a 2.5 second target means roughly 800 ms or less at the 75th percentile. In a single HAR on a fast connection, a wait over 600 ms for the document is worth investigating.
Why do the phase totals add up to more than the page load time?
Requests run in parallel. Adding every request's wait time counts overlapping periods several times, so the totals describe how much of each kind of delay occurred, not how long the page took.
Last reviewed by the A2Z.Tools team against the sources listed above.
