Guide
Reading a HAR file: where page load time goes
When a page is slow for one customer and fine for everyone else, the most useful evidence is a HAR file: a recording of every network request the browser made, with timings, sizes, headers and status codes. Support teams ask for them, but a HAR is a large JSON document that is hard to read without DevTools. This analyzer turns it into a waterfall and a few summaries, in your browser, so the file and the secrets inside it stay with you.
Recording a HAR
In Chrome or Edge, open DevTools, go to the Network tab, tick “Preserve log” and “Disable cache”, reload the page and reproduce the problem, then right-click the request list and choose “Save all as HAR”. Firefox has the same option under the gear menu of its Network panel, and Safari exports from the Network tab of Web Inspector. The file follows the HAR 1.2 format, which every major browser writes.
The phases of a request
Each bar in the waterfall is split into the phases the browser recorded. Queued is time waiting for a free connection. DNS looks up the host name, Connect opens the TCP connection and TLS negotiates encryption; those three only appear on the first request to a host. Send is uploading the request, Waiting is the time to first byte while the server works, and Download is receiving the body. Long waiting points to the server; long download points to large files or slow bandwidth.
Totals and groupings
The summary counts requests, adds up bytes transferred, and reports when the last request finished and when the page’s load event fired. Errors include any response with status 400 or above and requests that failed with status 0, such as blocked or cancelled ones. Two tables group the requests by content type, such as script, image or font, and by host, sorted by bytes, which quickly shows whether third-party domains or one huge image dominate.
A worked example
The Sample is an eight-request capture of a small shop page. It transferred 749 KB, the last request finished at 1,203 ms and onLoad fired at 1,460 ms, with one error: a missing PNG returning 404. Sorting by size puts shop.example.com/img/hero.jpg first, a 402 KB image that took 583 ms, most of it downloading. The by-type table shows the JavaScript bundle and that hero image together account for most of the bytes, which is where optimisation should start.
Using the filter
Type part of a URL, a type such as script or a status such as 404 to narrow the waterfall. Combined with sorting by duration, this answers questions like “which API call is slowest” in a couple of clicks.
HAR files and privacy
A HAR contains complete request and response headers, so session cookies, Authorization headers and sometimes form data and API responses are inside. This page reads the file only in your browser and never uploads it, but anyone you send a HAR to can replay those sessions. Remove sensitive values with the Redact Log Secrets tool, or log out of the session after recording so its cookies stop working.
Limits of the data
The analyzer shows what the browser recorded. Safari omits some timing phases, cached responses may report zero size, and sizes depend on whether the browser included header bytes. Timings in a HAR reflect one load on one network, so record several when a problem is intermittent.
Related tools
- Page Weight Calculator sets a budget from the sizes you find.
- Core Web Vitals Calculator rates the user-facing metrics.
- Access Log Analyzer looks at the same traffic from the server side.
- Redact Log Secrets removes tokens before you share files.
Checked against the current version of the HAR Analyzer on .