A support engineer asks for a HAR file, and suddenly you're in browser DevTools wondering what exactly you're supposed to capture, open, and learn from it. That situation is common because a HAR file is one of the fastest ways to turn “the site feels slow” into something you can inspect. 
If you'd rather avoid manual checks every time performance gets weird, use PageSpeed Plus to monitor pages continuously, track Web Vitals, and catch regressions before they become support tickets.
A page feels slow, a checkout step fails, or a script hangs only on one browser. Before changing code, you need evidence from the browser itself. A HAR file, short for HTTP Archive, gives you that record.
According to the HAR file format overview), a HAR file is a JSON-formatted archive that captures the network requests and responses involved in loading a page. The format was specified as HAR 1.2 and uses UTF-8 encoding. In practice, that means you can export one file and inspect the same request sequence in different tools without manually rebuilding the session.
The value of a HAR file is precision. It helps answer specific questions: which request returned an error, which resource spent too long waiting, whether redirects stacked up, or whether the backend was slow to respond. That makes HAR analysis useful for debugging and first-pass performance work, especially when DevTools alone is too fleeting and a screenshot of the waterfall is not enough.
A HAR file only captures one recorded session.
That trade-off matters. A single capture can explain what happened during one test run, but it cannot show trends, real-user variation, or whether the issue is recurring across pages and time windows. Manual HAR analysis works best alongside field metrics and automated checks. If you want the user-facing view of performance that sits above raw request logs, this Core Web Vitals guide is the right companion. Tools such as PageSpeed Plus fit into that broader workflow by monitoring key changes continuously, while HAR files help you inspect the exact request chain behind a spike or regression.
| Term | What it means |
|---|---|
| HAR | HTTP Archive file |
| Format | JSON |
| Standard | HAR 1.2 |
| Encoding | UTF-8 |
A common first run goes like this. The page stalls, someone exports a HAR after three reloads, and the file is full of cached assets, missing redirects, and unrelated requests from other tabs. You can still open that file, but you cannot trust it. Good HAR analysis starts with a clean capture.
Open DevTools before reproducing the issue. In the Network tab, enable Preserve log and disable cache. Those two settings prevent the browser from dropping requests during navigation and from hiding resources that were served locally instead of fetched over the network.
Use a private browsing window if the session includes logins, checkout flows, or API calls that may expose tokens, cookies, or personal data. HAR files often contain more than teams expect. Review the file before sending it to anyone outside engineering or support.
Then reproduce one specific journey. Keep it narrow. If the problem is a slow product page after a redirect from search, record exactly that path and stop. Long recordings create noise, make the waterfall harder to read, and slow down review because every extra request competes for your attention.
Chrome, Edge, and Firefox all let you export the session from the Network panel as a HAR file, usually with an option to include response content. Save the file immediately after the issue occurs so you do not overwrite the evidence with a second attempt that behaves differently.
Manual capture is still the right starting point for first investigation. Once the path is stable, teams usually turn that same flow into a repeatable script. A practical next step is to pair HAR review with headless browser testing for scripted diagnostics, so the same journey can be checked again without relying on a person to reproduce it perfectly each time.
For a quick HAR file open workflow, import the .har file back into browser DevTools. In Chrome and Edge, open the Network panel and load the file there. Firefox supports HAR import as well. That gives you the same request list, timings, headers, and waterfall structure you use during live debugging, which is why native browser tools are usually enough for the first pass.
Use an online viewer if you need a fast visual check or want to send a simpler waterfall view to another engineer. That is useful for collaboration, but browser DevTools remain the better place for detailed inspection because filtering, request headers, cookies, initiators, and timing breakdowns are closer at hand.
A video walkthrough helps if you haven't done this before.
The waterfall chart shows requests in sequence. Each row is one request, and the horizontal bar shows where time went. Long bars are not automatically a problem. Long bars without a clear reason usually point to queueing in the browser, slow server work, or a heavy response body.
Start with order, not duration. Junior developers often click the slowest request first and miss the underlying cause. A request can be slow because something earlier blocked it, because the browser had no free connection, or because a script, stylesheet, or redirect delayed everything behind it.
Look for these patterns:
For a more detailed reading guide, keep this explanation of how to interpret a waterfall report open while you review the file.
A practical HAR review starts with three questions. Which request starts the chain, which request stalls the chain, and which request fails outright?
Most DevTools panels show a timing breakdown for a selected request. You do not need every field memorized. You do need to know what each phase suggests so you do not chase the wrong fix.
| Timing Phase | What It Means | What a High Value Indicates |
|---|---|---|
| Stalled | Time waiting before the request begins moving | Browser queueing or connection contention |
| DNS Lookup | Time spent resolving the hostname | Slow name resolution |
| Connecting | Time spent establishing the connection | Handshake or network setup delay |
| Waiting | Time before the first byte returns from the server | Slow server processing |
| Content Download | Time spent transferring the response body | Large resource or constrained throughput |
The Waiting phase gets attention first because it reflects time to first byte. If that segment dominates, inspect application work on the server side. Database queries, cache misses, expensive template rendering, and slow upstream APIs are common causes. If Content Download is the largest segment, the server may be responding quickly and the problem is payload size or network throughput instead.
Context matters. A long DNS or connect phase on one request may be noise. The same pattern across many hosts usually points to a network path, TLS setup, or third-party dependency issue. Teams handling production incidents alongside broader reliability work often pair HAR findings with logs, traces, and metrics so they are addressing SaaS reliability issues effectively instead of treating one browser capture as the whole story.
Headers deserve the same level of attention. Check cache headers, compression, content type, and redirects. If static assets are not cacheable, the browser keeps paying for them. If a text asset ships without compression, download time grows fast. HAR is strong for this kind of manual diagnosis, but it is still a point-in-time capture. Once you know which request pattern matters, repeatable monitoring is the better way to confirm whether the issue is isolated or part of a recurring performance problem.
A HAR file earns its keep when it leads to a change. Otherwise you just have a prettier version of guesswork. The practical move is to map each symptom in the log to the component that can be fixed.
If the waterfall shows oversized image downloads, start with compression, modern image formats, and lazy loading for below-the-fold media. If blocking JavaScript appears early and pushes later requests back, move non-critical scripts to async or defer where the application allows it. If an API call dominates the waiting phase, profile the endpoint and look for expensive backend work before touching front-end code.
Third-party scripts deserve special scrutiny. They often look small in implementation effort and large in runtime cost. A HAR makes that visible because their requests sit next to your first-party requests in the same timeline.
Google's PageSpeed Insights documentation notes that the tool reports on user experience across both mobile and desktop devices and provides actionable suggestions for improvement as part of Google's developer tools ecosystem. That makes it a useful second opinion after HAR review, especially when you want to compare a one-off browser session with broader lab guidance.
When the issue extends beyond one page, manual HAR analysis stops scaling. That's where regular monitoring, repeatable testing, and operational thinking matter. Teams working on addressing SaaS reliability issues effectively usually combine request-level debugging with alerts, trends, and environment-wide visibility. The same principle applies to web performance.
If you're running WordPress, the implementation path is often straightforward once the culprit is clear. A well-built WordPress plugin can handle page caching, compression, CSS and JavaScript optimization, and lazy loading so fixes don't depend on hand-tuning every template.
You open a HAR to debug a slow checkout, and the request that looked slow in the browser is missing from the export. That usually means the problem started during capture, not during analysis. HAR files are useful, but they are fragile enough that one bad setting can turn a solid debugging session into guesswork.
Start with the boring checks. They solve a surprising number of bad captures.
If key requests are missing, check whether Preserve log was enabled before the page navigation or user action. If static files are absent or timings look unrealistically fast, capture again with cache disabled. If the file refuses to load in one viewer, the HAR may still be valid JSON and too large or too messy for that tool to render cleanly.
A practical triage order works well:
Large HARs create another common problem. They contain enough detail to be useful, but they also become hard to inspect, share, and compare. For manual debugging, shorter captures are usually better. For ongoing coverage across many pages and releases, automated monitoring is a better fit because it tracks trends without forcing someone to inspect giant exports by hand.
The bigger mistake is treating a HAR like a harmless screenshot. It is often closer to a session transcript.
The Webvizio article on downloading and analyzing HAR files is right to call out the security risk here. HAR files can include cookies, authorization headers, form payloads, and response data. Opening one for inspection is low risk. Uploading it to a tool that can replay requests, or sending it to another team without review, is a different decision.
Review these fields before you share anything:
If the capture came from a logged-in WordPress session, clear caches before you retest so you are not comparing fresh requests against stale output. This guide on clearing WordPress cache after performance changes is useful when repeated HAR captures do not line up with what you expect.
Manual HAR work is still worth learning. It helps isolate one broken flow, one bad deployment, or one expensive dependency. Once the same issues start appearing across multiple pages or environments, teams usually need repeatable tests, historical baselines, and alerts alongside ad hoc HAR review. That is where automated monitoring adds value. It does not replace HAR analysis. It makes sure you do not have to wait for the next outage or support ticket to run it.
The key follow-up topics are already covered where they matter in the article body. That is the better place for them.
If you want to keep building from this point, revisit the earlier sections on Web Vitals, headless browser testing, waterfall reports, and cache clearing in the context where each one supports a specific HAR workflow. That structure is easier to use during real debugging because the reference sits next to the decision you are making, not in a generic list at the end.
HAR analysis works best as one tool in a larger performance practice. Use it to inspect a single session closely. Use automated monitoring to catch the patterns that repeat across releases, pages, and environments.