How to Read a HAR File and Find Slow Requests

A customer reports the page takes eight seconds. You can’t reproduce it, so you ask them to export a HAR file from their browser’s network panel. They send you a four megabyte JSON file.

Two things about that file. It contains exactly what you need to diagnose the problem, and it also contains their session cookie.

Read the HAR before you share it

A HAR records every request the browser made, including headers. That means cookies, Authorization headers, and request bodies — anything submitted in a form, including credentials if a login happened during the capture.

Treat a HAR like a credential dump:

• Never paste one into a service that uploads it.
• Never attach one to a public issue tracker without scrubbing.
• Rotate anything sensitive if a HAR has been shared carelessly.

Browsers’ network panels usually offer an option to export without sensitive data, and it’s worth asking for that version when requesting one from a user.

What to look at first

Not the waterfall. A waterfall read top to bottom shows you the order things happened, which is mostly the order the HTML referenced them — informative about structure, rarely about the delay.

Sort by time instead. The slowest handful of requests is where the eight seconds went. Usually it’s two or three entries, often to a third-party host, and the rest of the capture is noise.

Then look for these patterns:

Repeated identical requests. The same URL fetched several times means a missing cache header or a script fetching in a loop. It’s one of the easiest wins available.

Errors. 404s on fonts and images don’t block the page but they do consume connections and, for fonts, can delay text rendering.

Blocked or queued time. A request that spent four seconds queued wasn’t slow to serve — it was waiting for a connection, which points at too many parallel requests to one host.

Time to first byte on the document request. If that’s the bulk of the delay, the problem is server-side and nothing in the front end will fix it.

Common mistakes to avoid

• Uploading a HAR to an online analyser without checking what’s in it.
• Reading the waterfall linearly instead of sorting by duration.
• Optimising the biggest file when the slowest request is a small one waiting on a server.
• Ignoring the redirect chain at the very start, which can account for a second before any content is requested.
• Diagnosing from your own capture when the user’s problem is geographic or network-specific.

How to do it with HAR File Viewer

The HAR File Viewer reads the capture in your browser, so the file never leaves your device.

1. Export the HAR from a browser’s network panel, using the redacted option if available.
2. Sort by time and look at the slowest few requests.
3. Check for repeated identical URLs and any errors.
4. Look at where the time went within each slow request — queued, waiting, or downloading.

The HAR specification documents every field if you need the detail. Other developer tools are in the tools directory.

Frequently asked questions

Does a HAR file contain sensitive data?

Yes — cookies, authorisation headers, and request bodies including anything submitted. Treat it like a credential dump and scrub it before sharing.

What should I look at first?

The slowest few requests and anything returning an error. A waterfall read top to bottom mostly shows the order things happened, not what caused the delay.

Why do I see the same URL requested repeatedly?

Usually a missing or too-short cache header, or a script fetching in a loop. Repeated identical requests are one of the easiest wins in a slow page.

Final thought

Sort by duration, fix the top three, and re-capture. Two or three requests almost always account for the delay, and the other hundred and forty are just the page loading.

Try the free HAR File Viewer