HAR File Analyzer

Front-end engineers investigating a slow page load, SEO specialists checking whether render-blocking resources bloat the critical path, and support teams reproducing a customer performance complaint all work from the same artifact: a HAR file exported from browser DevTools. Raw HAR JSON runs to hundreds of megabytes on media-heavy pages and hides the useful signals inside nested timing objects.

This analyzer reads the file locally, then surfaces the numbers that drive decisions: total requests, transfer bytes, cache hit ratio, the ten largest resources, the ten slowest requests, and any redirect chains buried in the trace. Nothing is uploaded, so traces containing session cookies and internal URLs stay on your machine.

How the analyzer reads a HAR file

A HAR document wraps an array of request entries under log.entries. The analyzer validates that root shape first and rejects anything else with a pointed error, because pasting a regular API response or a DevTools performance JSON produces confusing half-results if the structure check is skipped. Once validated, each entry is flattened into a single summary row: method, URL, host, status code, MIME type, transfer size, resource size, total time, wait time, cache status, and redirect target.

Transfer size prefers response.bodySize when it is positive, falling back to content.size. A negative bodySize combined with a positive content.size marks the request as served from cache, which increments the cache hit counter and keeps zero-byte rows from dragging down the bandwidth total. Hostnames are extracted with the URL constructor so counting per-domain traffic handles ports, query strings, and sub-paths correctly.

Redirect detection builds an index of every request URL, then walks each 3xx entry that carries a redirectURL field. When the redirect target appears as a later entry in the same trace, the walk continues until a final non-redirect response is reached. Each multi-hop sequence is reported in order, so you can see exactly which intermediate URL adds a round trip before the real content arrives.

Before and after: reading a real trace

Raw HAR excerpt exported from Chrome DevTools:

{
 "log": {
  "version": "1.2",
  "entries": [
   {
    "request": { "method": "GET", "url": "https://shop.test/old" },
    "response": { "status": 301, "bodySize": 120,
      "redirectURL": "https://shop.test/new" },
    "time": 180, "timings": { "wait": 90 }
   },
   {
    "request": { "method": "GET", "url": "https://shop.test/new" },
    "response": { "status": 200, "bodySize": 84000,
      "content": { "size": 210000, "mimeType": "text/html" } },
    "time": 640, "timings": { "wait": 410 }
   }
  ]
 }
}

Analyzer output:

Requests: 2    Transfer: 84.1 KB    Cache hits: 0
Redirect chains (1):
  https://shop.test/old -> https://shop.test/new (final 200)
Slowest: GET /new 640 ms total, 410 ms server wait
Compression ratio on /new: 84 KB over the wire vs 210 KB
  uncompressed (2.5x reduction from brotli)

Who uses this analyzer

Common mistakes when reading HAR files

• Pasting truncated HAR JSON. DevTools sometimes writes multi-hundred-megabyte files that editors silently cut off when opened in a text box. The analyzer will report a JSON parse error pointing at the truncation; export the file again with fewer domains throttled or use the file picker, which reads the full binary without a text round trip.
• Confusing wait time with download time. A high wait value points at server processing or a slow edge; a high total time with low wait points at a large payload over a slow link. The slowest requests table lists both numbers so you can tell which side of the wire is the problem.
• Ignoring cache hits when totals look small. A second-visit trace dominated by cache hits will show a tiny transfer total that does not reflect the first-visit experience. Clear the browser cache and record a cold-load HAR when you need the numbers real visitors see on their first arrival.
• Analyzing a HAR from a different page than the complaint. Support tickets often attach a HAR of the home page when the slowness was reported on checkout. Confirm the document URL in the trace matches the template in the ticket before drawing conclusions from the resource lists.

Best practices for performance traces

• 1.Record cold-load traces with the cache disabled and DevTools throttling set to Fast 3G or Slow 4G, matching what mobile visitors actually experience.
• 2.Strip cookie and authorization headers from any HAR you attach to a public issue before sharing it, even when you plan to analyze it locally first.
• 3.Target a cache hit ratio above 70 percent on repeat views of the same template by fingerprinting static asset filenames and setting long max-age values with immutable.
• 4.Collapse redirect chains to a single hop on the document URL; each removed hop is one full round trip before any other request can start.

Frequently asked questions