har-analyzer

name

har-analyzer

description

Audits .har (HTTP Archive) files generated by the browser's Network tab, producing an executive report on performance, API failures, security, and third-party impact. Use whenever the user sends/cites a .har, asks for a network tab analysis, investigates slow requests, 4xx/5xx errors, high TTFB, cache/compression issues, data leaks in URLs, permissive CORS headers, or the impact of third-party scripts — even if they do not explicitly say "audit" or "report".

HAR Analyzer

CRITICAL LANGUAGE RULE: Primary interaction and the final output report must follow the user's conversational language. Do not output the report in English if the user is speaking another language (e.g., Portuguese). Translate the structure of the report on the fly to match the user's language.

Systematic audit of .har files to deliver an executive diagnosis to the user, with numbers, named offenders, and prioritized recommendations.

Overview

Raw .har files have two problems that make direct analysis unfeasible:

1. Size: a typical HAR has tens of megabytes — base64 of images, multi-MB API payloads, dense headers. Reading it raw ruins the context window and, worse, induces hallucination because the LLM needs to do arithmetic on hundreds of entries.
2. Sensitivity: HARs leak credentials (cookies, JWTs in OIDC responses, signed WebSocket/S3 URLs, PII in querystrings). Moving raw data to the LLM is risky.

The solution: a deterministic pre-processor (scripts/sanitize_har.py) that sanitizes, splits into chunks by audience (APIs, statics, third-parties) and calculates a summary.json with the numbers ready. The LLM then interprets instead of counting.

Core Rules (Hard Gates)

1. **Never count manually:** Use `summary.json` numbers. Never guess totals, percentages or rankings. 2. **Run the pre-processor:** Always parse the `.har` using the python script before analyzing. 3. **Respect user language:** Translate your output to match the user's current conversational language.

Execution Flow

1. Locate the .har and run the pre-processor

Identify the absolute path of the .har the user wants to analyze. If they don't say, look in the current directory or ask. Then, run the script with python3 (some environments don't have python in PATH):

python3 <skill_path>/scripts/sanitize_har.py <absolute_path_to_har_file.har>

Replace <skill_path> with the absolute path of this skill (e.g.: ~/.agents/skills/har-analyzer). Use the path that appears in available_skills/agent_skills of your session.

Without passing the second argument, the script automatically creates a folder next to the .har, named <har_name>.chunks/. This avoids collisions when working with multiple HARs.

Example: for ~/Downloads/slow-checkout.har, the output goes to ~/Downloads/slow-checkout.chunks/ and contains:

File	Content
summary.json	Deterministic metrics: totals, % error, top-10 slowest, top-10 heaviest, duplicates, compression offenders, security findings. Read this first.
chunk_api.json	XHR/Fetch requests from the main domain — focus on API diagnosis.
chunk_static.json	Documents, scripts, CSS, images, fonts from the main domain — focus on performance.
chunk_third_party.json	Everything from external domains — focus on third-party impact.

2. Start with summary.json

This file already gives you almost the entire skeleton of the report:

• totals → request count, total transferred weight, first/third party partition.
• status_breakdown → 2xx/3xx/4xx/5xx distribution.
• errors_4xx_5xx → nominal list of each failure.
• top_slowest / top_heaviest → top 10 offenders in time and bytes.
• duplicate_requests → same URL called N times (symptom of N+1 or lack of state cache).
• missing_compression → large textual resources without GZIP/Brotli.
• security_findings → permissive CORS, PII in querystring, leaked tokens in response body.
• third_party_domains → external domains by volume.

3. Deep dive reading only the chunks that matter

• To detail an error in errors_4xx_5xx, open chunk_api.json and search for the URL.
• To understand why a call is in top_slowest, look at timings of the corresponding entry (DNS, connect, ssl, send, wait = TTFB, receive).
• To judge if a 3rd-party is worth the weight, cross third_party_domains with chunk_third_party.json.

Do not try to read all chunks at once. They can have hundreds of entries — read them in a targeted way.

4. Write the report as a physical .md file

The report must be saved to disk, next to the .har, named <har_name>.report.md. This allows the user to version, share, or attach it to a ticket.

Also print in the chat a short summary (3-5 lines) pointing to the path of the generated file and the 2-3 most critical findings, for the user to decide if they want to investigate further. Provide this summary in the user's conversational language.

Output Contract

Use this template. Translate the headings and boilerplate text to the user's conversational language.

# Network Audit — [har name]

> Analyzed HAR: `[file path]`  
> Main domain: `[main_domain]`  
> Total requests: [N] ([X] first-party / [Y] third-party)  
> Transferred weight: [readable size]  
> Status distribution: [status_breakdown summary]

## 1. Executive Summary

[3–5 bullets of the most critical findings, with numbers. Ex.: "12 5xx requests concentrated in /api/notification...", "15 MB main bundle with no effective chunking...", "228 endpoints with open CORS (*)..."]

## 2. Performance and Loading

### Top slowest requests
| # | Time | Method | URL | Status |
|---|---|---|---|---|
[Use top_slowest from summary]

### Top heaviest resources
[Use top_heaviest. Comment when size seems unreasonable for the type.]

### Compression and cache
[List missing_compression offenders. Point out if static resources lack Cache-Control / Expires.]

## 3. API Diagnosis

### Failures (4xx/5xx)
[Group by endpoint. For each, show status, number of occurrences, and — if you can extract from chunk_api — a sentence about the error body.]

### Duplicate requests and likely N+1
[Use duplicate_requests. Flag when pattern suggests missing debounce/state cache.]

### High latency
[Identify APIs where `wait` (TTFB) dominates total time — usually slow backend, not network.]

## 4. Security Audit

### Permissive CORS
[List hosts returning Access-Control-Allow-Origin: * on authenticated endpoints.]

### PII / secrets in URL
[Use security_findings.pii_in_query.]

### Leaked tokens in response
[Use security_findings.tokens_in_response. Remind user original HAR contains clear text — suggest not versioning it.]

## 5. Third-Party Impact

[Use third_party_domains. For each relevant domain, indicate volume & approx weight. Point out clear offenders.]

## 6. Prioritized Recommendations

1. [Concrete action — always indicate where to act in code/infra]
2. ...

---

> Analysis generated from sanitized chunks in `[.chunks folder path]`.  
> Original HAR may contain cookies, tokens, and PII in plain text — avoid versioning.

Principles for writing the report

• Name specific offenders. "There are heavy resources" is useless; "23.bundle.js is 15MB" is actionable.
• Use summary.json numbers. Never guess — they are already computed.
• Distinguish symptom from cause. High TTFB != slow network (likely backend).
• Acknowledge boundaries. If HAR lacks info, say it.
• End with clear priority. User needs to know what to do Monday morning.