HAR File Analysis: How to Diagnose Slow API Endpoints & Network Bottlenecks

HTTP Archive (HAR) is a JSON-formatted standard format (standardized by the W3C Web Performance Working Group) used to log detailed HTTP interactions between a client browser and backend web servers. When diagnosing intermittent production latency, high Time to First Byte (TTFB), CORS preflight overhead, or third-party script blocking, HAR files provide the complete network ground truth.

This engineering guide explains how to capture and inspect HAR files, interpret each phase of the network timing waterfall, and systematically resolve API performance bottlenecks.

---

1. Deconstructing the HAR JSON Schema

A .har file contains a root log object holding browser version metadata, pages, and an array of entries representing individual HTTP transactions:

{
  "log": {
    "version": "1.2",
    "creator": { "name": "WebInspector", "version": "537.36" },
    "pages": [],
    "entries": [
      {
        "startedDateTime": "2026-09-04T12:00:00.000Z",
        "time": 245.8,
        "request": {
          "method": "POST",
          "url": "https://api.example.com/v1/checkout",
          "headers": [],
          "queryString": [],
          "postData": { "mimeType": "application/json", "text": "{\"cartId\":123}" }
        },
        "response": {
          "status": 200,
          "statusText": "OK",
          "headers": [],
          "content": { "size": 1420, "mimeType": "application/json" }
        },
        "timings": {
          "blocked": 1.2,
          "dns": 14.5,
          "connect": 32.1,
          "ssl": 28.4,
          "send": 0.4,
          "wait": 165.2,
          "receive": 4.0
        }
      }
    ]
  }
}

---

2. Reading the Network Timing Waterfall

The timings object inside each HAR entry breaks down latency into distinct phases:

[ Blocked ] -> [ DNS ] -> [ Connect (TCP) ] -> [ SSL/TLS ] -> [ Send ] -> [ Wait (TTFB) ] -> [ Receive ]

Breakdown of Timing Phases

Timing Phase	What It Measures	Likely Root Cause If High
Blocked / Stalled	Time queued in the browser before socket connection	Browser connection limit reached (max 6 HTTP/1.1 connections per host), or CPU thread saturation.
DNS Lookup	Resolving domain name to IP address via DNS resolvers	Uncached DNS, slow authoritative nameservers, or excessive third-party domain lookups.
Connect (TCP)	Completing the 3-way TCP handshake (SYN, SYN-ACK, ACK)	Geographic distance, high packet loss, or lack of persistent keep-alive connections.
SSL / TLS	Completing cryptographic handshake and certificate exchange	Unoptimized TLS handshakes (missing TLS 1.3 / 0-RTT session resumption) or large certificate chains.
Send	Time taken by client to write the HTTP request payload onto the socket	Large multipart file uploads, slow upstream client network bandwidth.
Wait (TTFB)	Time from request transmission until first response byte arrives	Server-side slowness: Unindexed database queries, slow microservice RPC calls, un-cached SSR rendering.
Receive / Content Download	Time spent reading the response stream to the end	Massive uncompressed response payloads, unpaginated API lists, slow client downlink.

---

3. Diagnosing Common Production API Bottlenecks

1. High TTFB (timings.wait > 500ms)

• Symptom: The browser connects quickly, but spends hundreds of milliseconds waiting for the first byte.
• Root Cause: Backend execution overhead. Check for N+1 database queries, cold-start lambda initialization, unoptimized Redis serialization, or synchronous external API calls.
• Fix: Implement Redis caching headers (Cache-Control: s-maxage=300, stale-while-revalidate), optimize DB indexes, or stream response chunks.

2. Cascading CORS OPTIONS Preflight Delays

• Symptom: Every POST or PUT request is preceded by an OPTIONS request taking 100–200ms, doubling overall API latency.
• Root Cause: Missing or short Access-Control-Max-Age response headers, forcing the browser to issue preflight OPTIONS requests on every API call.
• Fix: Return Access-Control-Max-Age: 86400 (24 hours) on all preflight responses to let the browser cache CORS approval.

3. Connection Head-of-Line Blocking (HTTP/1.1 vs HTTP/2 vs HTTP/3)

• Symptom: High blocked time across dozens of concurrent static asset or microservice requests.
• Root Cause: HTTP/1.1 limits browsers to 6 parallel TCP connections per origin. Requests beyond 6 must wait in a queue.
• Fix: Enable HTTP/2 or HTTP/3 (QUIC) on your reverse proxy (Cloudflare, Nginx, ALB) to allow single-socket multiplexing.

4. Uncompressed JSON Payloads (content.size vs bodySize)

• Symptom: High receive time on large API responses.
• Root Cause: Missing Content-Encoding: gzip or Content-Encoding: br (Brotli) compression headers.
• Fix: Enable Gzip or Brotli compression on your API gateway or web server for application/json payloads.

---

4. Sanitizing Sensitive Data in HAR Files

HAR files capture complete HTTP transactions, including:

• Authorization tokens (Bearer eyJ...)
• Cookies (sessionid=..., csrf_token=...)
• Credit card details, API keys, or PII in request/response bodies

Before sharing a HAR file with third-party vendors or attaching it to an issue tracker, always scrub authentication headers and sensitive cookies!

---

Frequently Asked Questions

How do I export a HAR file from Google Chrome or Firefox?

1. Open DevTools (F12 or Cmd + Option + I) and switch to the Network tab.
2. Ensure the red recording icon is active and check Preserve log.
3. Reproduce the bug or slow API action.
4. Click the Export HAR icon (downward arrow) or right-click any request and select Save all as HAR with content.

How can I inspect and convert HAR files online?

Use the free HAR Analyzer and HAR to Postman Converter on DevFlow to visualize timing waterfalls, filter slow endpoints, and convert recorded sessions into executable API collections.