Mightora · HAR troubleshooting guide
HAR performance timings explained
Understand HAR network performance timings, identify slow APIs and interpret DNS, SSL, wait time and P95 without confusing duration totals.
HAR files separate parts of a network request so you can understand whether a delay is more likely to be caused by connection setup, the server, or the transfer. The fields are diagnostic clues rather than definitive root-cause evidence.
Key timing measurements
| Measurement | What it suggests |
|---|---|
| DNS | Time resolving a hostname to an IP address; often absent or skipped on reused connections. |
| Connect | Time establishing a network connection; high values can indicate latency or connection problems. |
| SSL / TLS | Time involved in negotiating a secure connection, when measured by the capturing browser. |
| Wait | Time until the first response byte, often associated with back-end processing or network delay. |
| Receive | Time spent receiving the response payload, which can increase with payload size or bandwidth limitations. |
| Total request time | The overall duration recorded for one request; it may include phases beyond those displayed in a summary. |
Browsers may record an unavailable timing as -1. In the dashboard, unavailable timings are shown as zero for aggregate convenience, which is not proof that the phase took zero milliseconds.
Understanding P95
P95 means that approximately 95% of the recorded request durations were at or below the displayed value. A HAR sample might contain only a few dozen requests, so this number should not be confused with a production service-level objective. Group different API endpoints before drawing conclusions about service performance.
Why request totals aren't page load time
Network requests overlap. For example, three concurrent requests each taking two seconds do not imply six seconds of page load time. Use the browser's page-load markers and the HAR start times to understand critical-path behaviour. The Mightora dashboard's host totals are cumulative durations, not wall-clock elapsed time.
Typical troubleshooting patterns
High wait times across several endpoints may indicate server or upstream processing delays. High DNS or connect durations concentrated on one host may indicate connection setup issues. Large response bodies paired with high receive times suggest examining API payload size, image optimisation or compression.
For a practical walkthrough, see how to analyse a HAR file.
Try it yourself: Open the free private HAR analyser or download the offline ZIP.
