A slow page produces several different questions: which requests were slow, whether requests overlapped, and whether a response was unexpectedly large. A HAR archive can preserve useful evidence after the original browser session ends. It is a recording, however, rather than a script that must be replayed. This guide uses the local HAR request analyzer to turn a recording into a short investigation plan without contacting the recorded addresses.
Preserve the recording before interpreting it
Keep an untouched copy of the export and note when, where and how it was recorded. Record the browser, relevant page action and whether caching was enabled. A recording of a warm repeat visit answers a different question from a fresh navigation. If the problem depends on signing in or opening a particular panel, write that context down while it is still available.
HAR exports may contain URLs, query parameters, headers and bodies with sensitive information. Check the browser's export options and inspect the actual file before sharing it. Sanitized export options reduce some risks but do not establish that every application-specific field is harmless. The analyzer works locally; its report can still expose full request URLs. Review that report before copying it into an issue.
Establish a controlled three-request example
For a reproducible exercise, use HAR version 1.2 with three synthetic entries. Give each entry a request method and URL, a response status and bodySize, and a numeric time. These are the fields this analyzer needs; a complete interoperable HAR export has additional structure. Do not mistake a minimal tool fixture for a comprehensive exporter implementation.
Use durations of 120, 180 and 60 milliseconds. Assign body sizes of 1000, 2000 and -1 bytes, with statuses 200, 200 and 404 respectively. The expected report is three requests, one status in the 400–599 range, 360 milliseconds of summed durations, 3000 known response-body bytes and one unknown size. The slowest entry should be the 180-millisecond request.
This hand calculation gives you an independent reference. Change the unknown size to zero and rerun: known bytes remain 3000, but the unknown count becomes zero. That distinguishes an empty recorded body from a body whose size was not available. Never replace an unknown measurement with zero simply to make a total easier to present.
Keep duration sums separate from elapsed time
Suppose all three requests start together at time zero. Their completion times are 120, 180 and 60 milliseconds. The interval covering those requests is 180 milliseconds, while their durations still sum to 360. If they instead start sequentially, the same durations could span 360 milliseconds. The sum alone does not tell you which arrangement occurred.
The local analyzer reports a sum, not a page-load metric or a reconstructed waterfall. Use the browser's network panel and the original start timestamps when investigating ordering, dependencies or concurrency. Also separate network completion from the moment the interface becomes usable. A page can spend time executing scripts, laying out content or waiting for application logic after a response arrives.
Interpret the size label literally
The report sums known response.bodySize values. This is not a claim about all bytes transferred over the connection. Headers, compression, caching and exporter behavior can affect the relationship between recorded fields and the transfer measurement you actually want. The historical HAR 1.2 draft documents unavailable values such as -1; it is a format reference, not a current browser performance recommendation.
Before comparing two runs, confirm that the fields were populated consistently. If one archive contains many unknown sizes, its lower known-byte total may reflect missing evidence rather than an improvement. State the unknown count beside the total. When the question is bandwidth consumption, choose and document the appropriate browser measurement rather than renaming this report's body-byte subtotal.
Turn ranked requests into testable hypotheses
Start with a slow entry and inspect its method, URL, status and context. A long duration suggests a candidate for investigation; it does not identify server processing as the cause. Connection setup, queuing and transfer can all matter. Look at detailed timing information in the original recording before proposing an optimization.
Likewise, the HTTP error count is a mechanical count of statuses 400 through 599. A deliberate missing-resource test may produce 404 correctly, while an application can return an unusable body with status 200. Read the endpoint's expected behavior and the initiating action. Prioritize failures that explain the user's symptom rather than treating every counted status as the same incident.
Leave a bounded investigation record
Write down the recording conditions, the relevant request, your hypothesis and the next observation that could confirm or reject it. For example, compare a cached and uncached run under otherwise similar conditions, or ask the service owner to inspect a matching server trace. Avoid replaying a recorded write request merely to see whether it is still slow.
Keep the original recording separate from any sanitized sharing copy. Note which fields were removed so another investigator understands the limits. The useful output is a focused question supported by recorded evidence: a candidate request, an honest measurement label and a clear next check. A local summary makes the archive approachable without pretending that its totals explain the entire page.
