How to Read a HAR File and Find What Slows a Page Down
A practical guide to analyzing a HAR file from browser devtools: find the slowest requests, biggest payloads, and render-blocking resources, all locally.
How to Read a HAR File and Find What Slows a Page Down
A page feels slow. Someone files a ticket that says "the dashboard takes forever." You open it, it loads in maybe three seconds, and now you have to figure out which of the eighty network requests on that page is actually to blame. This is the exact problem a HAR file solves, and most engineers never touch it because they assume it needs a full observability stack to be useful.
It doesn't. A HAR file is just JSON, and a few minutes of reading it tells you more than a hundred guesses.
What a HAR file actually contains
HAR stands for HTTP Archive. When you record a page load in the Network panel of Chrome, Edge, or Firefox and export it, you get a .har file: a JSON document listing every single network request the browser made. Each entry holds the request URL, the response status, the response headers, the content type, the transferred size in bytes, and a timings object that breaks the request down into phases like DNS lookup, connection, waiting for the first byte, and downloading the body.
That last part is the gold. The timings block is why a HAR file can answer questions a screenshot never could: not just "the page was slow," but "this one API call sat in wait for 1.8 seconds while everything else finished in 200 milliseconds." Multiply that detail across every request and you have a complete, timestamped record of the page load. Analyzing it surfaces three things fast: the slowest requests, the largest payloads, and what blocked the page from rendering.
To capture one yourself: open devtools, go to the Network tab, tick "Preserve log," reload the page, then right-click any request and choose "Save all as HAR with content." Drop that file into the HAR Performance Analyzer and you get a sorted report instead of a raw wall of JSON.
Finding the slow and oversized requests
The first pass is always the same: sort by time, then sort by size. These two lists usually overlap, but not always, and the difference matters.
A request can be slow because it is large (a 2 MB hero image takes time to download) or slow because the server was thinking (a database-backed API endpoint that took 1.5 seconds to respond before sending a 4 KB JSON body). The fix is completely different. The big image needs compression or a smaller variant. The slow API needs a backend look, caching, or a query index. A HAR file lets you tell these two apart in seconds, because the timings object separates wait time from receive time.
Pull the top five requests by total time and the top five by transferred bytes. If the same items show up on both lists, you have your heavy assets. If a request is near the top on time but nowhere on size, you have a server-side bottleneck dressed up as a frontend problem.
A worked example: the 2 MB image hiding in plain sight
Here is a real shape of this. I once profiled a marketing page that "felt heavy" on mobile. The total transfer was around 3.4 MB, which already seemed high for a single landing page. I exported the HAR, sorted by size, and the very first row was a background photo: hero-bg.png, 2.1 MB, served at full resolution to every device including phones. It alone was more than 60 percent of the page weight.
Right behind it, sorted by time this round, was a /api/recommendations call that sat in wait for 1.9 seconds. It returned a tiny payload, so it never showed up on the size list, but it delayed the part of the page that depended on it. Two requests, two completely different problems, both invisible until the HAR made them obvious.
The fixes wrote themselves: convert the hero image to a responsive webp set (it dropped to roughly 180 KB on mobile), and move the recommendations call so it no longer blocked the initial render. Page weight fell by about two-thirds, and the perceived load time followed. None of that needed a profiler or a paid tool. It needed one export and five minutes of reading.
Spotting render-blocking resources
Size and time tell you what is expensive. The next question is what is in the way. A render-blocking resource is one the browser must finish before it can paint the page: typically synchronous CSS in the <head> and scripts loaded without async or defer. In a HAR file you find these by looking at requests that finish early in the load timeline but whose content type is text/css or application/javascript and that sit on the critical path before the first content paint.
The signal to watch for is a cluster of CSS and JS requests all completing before any image or content request even starts. That ordering is the browser waiting. A render-blocking 400 KB stylesheet, or a third-party tag manager that pulls in four more scripts, can hold the whole page hostage while the user stares at a blank screen. The report flags weak cache headers on these static assets too, because a stylesheet that re-downloads on every visit is a render-blocker you are paying for repeatedly.
While you are in there, scan the host breakdown. A surprising amount of page weight and blocking comes from third-party requests: analytics, fonts, chat widgets, ad scripts. Each external host means another DNS lookup and connection setup before a single byte arrives, and you do not control any of their timings.
Everything stays on your machine
One detail worth stating plainly: a HAR file can contain private URLs, query strings, session cookies, and internal API routes. That is exactly why the analysis here runs entirely in your browser. The file is parsed locally in the page, nothing is uploaded, and no API is called. You still want to review a report before pasting it into a public issue, because hostnames and query parameters can leak, but the raw capture never leaves your device. For other local-first checks on the same engineering surface, the log error analyzer follows the same idea: read the data on your machine, report the actionable parts, send nothing out.
Turning the report into action
The point of reading a HAR is not the numbers, it is the to-do list. After a pass, you should walk away with an ordered set of fixes: resolve any failed 4xx or 5xx requests first because broken requests waste connections and retries, then attack the slowest request, then the largest payload, then the render-blocking static assets with weak caching, and finally trim third-party hosts you no longer need.
Export the request table as CSV if you want to hand it to a backend engineer, or paste the Markdown summary straight into a ticket so the slow-page complaint becomes a concrete, prioritized task. A HAR file turns a vague feeling into evidence, and evidence is what gets a performance bug actually fixed.
Made by Toolora · Updated 2026-06-13