HAR File Analyzer — find what made the page slow

A HAR file analyzer reads the recording your browser makes of a page load and turns it into the four or five numbers that actually explain why the page was slow. HAR — HTTP Archive — is a JSON format that every major browser can export from its network panel, and it contains one entry per request with full timing breakdowns, sizes, status codes, and headers. That is enormously useful data trapped inside a file that is unreadable by eye.

Arb Digital's team reviews HAR captures when a client reports that a page "feels slow", because the file distinguishes between the three completely different problems that all present the same way: too many requests, requests that are too large, and a server that takes too long to respond. Those need three different fixes. This page parses the capture in your browser using the built-in JSON parser, performs no network requests, and never transmits the file.

What This HAR File Analyzer Does

Load or paste a HAR and it reads every entry in log.entries, aggregating four headline figures: how many requests the page made, how many bytes were actually transferred over the network, how long the single slowest request took, and how much total time was spent blocked — that is, queued and waiting for a connection rather than doing anything useful.

Below that it ranks individual requests so you can see which specific resources caused the problem, sorted by whichever dimension you choose: total time, transfer size, blocked time, or server wait. Each line shows the method, status, timing, transfer size, and URL. Failed responses in the 4xx and 5xx ranges are counted separately, because a 404 on an asset is both a wasted round trip and usually a bug nobody has noticed.

How to Use It

1. Capture a HAR. Open your browser's developer tools, go to the Network panel, reload the page with recording enabled, then use the export or "save all as HAR" option.
2. Load the file with the file picker, or paste its JSON into the text box if you already have it open.
3. Pick a ranking dimension. Start with total time, then switch to transfer size and blocked time to see whether the problem is weight or queuing.
4. Click Analyse HAR and read the four summary figures before the detail — they tell you which category of problem you have.
5. Copy the breakdown into a ticket, after checking that no URL in it contains a token or session identifier in the query string.

How the Figures Are Calculated

Request count is the number of entries in the capture. Total transferred prefers each entry's _transferSize field, which browsers add to record actual bytes on the wire including headers and after compression. When that field is absent — some tools omit it — the analyzer falls back to response.headersSize plus response.bodySize, and it ignores any value of -1, which the format uses to mean "not available" rather than zero. Treating -1 as a real number is the classic HAR parsing bug and produces nonsensical negative totals.

Timing comes from each entry's timings object, which breaks the request into named phases: blocked, dns, connect, ssl, send, wait, and receive. The entry's time field is the total, and it should equal the sum of the non-negative phases. Any phase that does not apply — DNS for a reused connection, SSL for plain HTTP — is recorded as -1 and excluded here rather than counted as zero. The structure of these fields comes from the HAR 1.2 specification.

Blocked Time Is Not Server Time

This is the distinction that changes what you do next. blocked is time the request spent queued in the browser before it was sent — waiting for a free connection, waiting behind higher-priority resources, or waiting on the browser's own scheduling. wait is time between the request being fully sent and the first byte of the response arriving, which is genuine server processing plus network latency.

A capture where every request shows a large wait points at the backend: slow queries, no caching, cold starts. A capture where wait is small but blocked is large across dozens of requests points at connection contention — too many resources on one host, or a connection limit being hit — and no amount of backend optimisation will fix it. The remedies are entirely different: one calls for query tuning or caching, the other for fewer requests, bundling, or serving assets from a domain that supports better multiplexing.

Watch for the pattern in the sample data above: the JavaScript bundle and the stylesheet both show substantial blocked time despite quick server waits, which is exactly the queuing signature. The hero image shows the opposite profile — long receive time on a very large file, which is a weight problem that only compression or resizing will solve.

Transfer Size Versus Content Size

A HAR records two different sizes and confusing them leads to the wrong conclusion. content.size is the size of the resource after decompression — what the browser has to parse and execute. _transferSize and bodySize describe what actually crossed the network, which is smaller whenever compression is in play.

Both matter, for different reasons. Transfer size determines how long the download takes, so it is the number that matters on slow connections. Content size determines parse and execution cost, and for JavaScript that cost is often larger than the download cost on a mid-range phone. A 240 KB compressed bundle that expands to 812 KB of JavaScript is a modest download and a substantial main-thread expense. The gap between the two also reveals whether compression is configured at all: if content size and transfer size are nearly equal for a text asset, that asset is not being compressed and probably should be.

Entries served from cache typically report a transfer size of zero or a very small number while still showing a content size, which is correct — nothing crossed the network. If a repeat-load capture shows full transfer sizes on assets you expected to be cached, your cache headers are not doing their job.

What a HAR Contains, and Why You Should Scrub It

This is the part that gets skipped, so it is worth being blunt. A HAR captures request and response headers in full. That means every Cookie header, every Authorization header, every session token, every API key sent in a custom header, and every query string parameter. It captures POST bodies too, so a capture that includes a login includes the submitted password. It captures response bodies when the "with content" export option is used, so it may include personal data belonging to whoever was logged in.

A HAR file is therefore a credential, not a log file. If you send one to a vendor, a contractor, or a support desk, assume everything in it is compromised and rotate anything sensitive. Capture in a private window with a test account where possible, and use your browser's option to export without response content unless you specifically need bodies.

On this page: the file is read with the browser's own FileReader, parsed in memory, and discarded when you close the tab. There is no upload, no server round trip, and no storage. The output box shows only URLs, statuses, sizes, and timings — never headers or bodies — so a copied breakdown is far safer to paste into a ticket than the raw file. Check the URLs anyway, since tokens sometimes travel in query strings; our URL parser will break any suspicious one into its components.

Reading a Capture in Context

Two cautions about interpretation. First, a HAR is a recording of one load on one machine on one network, which is not the same as a measurement. Timings vary with connection quality, CPU contention, browser extensions, and cache state. Capture two or three loads before drawing conclusions, and note whether the cache was cold or warm — a warm-cache capture will look dramatically better and tell you nothing about a first-time visitor's experience.

Second, request timings do not tell you what the user actually saw. A page can finish every request in under a second and still render late because a blocking script delayed the first paint, and a page can keep loading analytics for another ten seconds after it looks entirely finished. The HAR tells you about the network; rendering behaviour is a separate axis. Google's Core Web Vitals documentation covers the user-facing metrics that complement this view. For the content side of the same audit, our website word count and meta tag generator cover page structure rather than page weight.

Common Mistakes to Avoid

• Sharing a raw HAR without scrubbing it — it contains cookies, auth headers, and often submitted form data in full.
• Treating -1 as a size or duration — in HAR it means "not available", and summing it produces negative totals.
• Confusing blocked time with server time — one calls for fewer requests, the other for backend work, and fixing the wrong one changes nothing.
• Drawing conclusions from a warm-cache capture — it hides exactly the cost that a first-time visitor pays.
• Comparing content size to transfer size as if they measure the same thing — one is parse cost, the other is download cost.

Related Free Tools From Arb Digital

Break a suspicious request URL into parts with the URL parser, look up an unfamiliar response code with the HTTP status code lookup, identify a client string with the user agent parser, shrink oversized stylesheets with the CSS minifier or scripts with the JS minifier, and confirm a captured MIME type with the MIME type lookup. The free online tools hub has the rest.

Frequently Asked Questions