⌘K 切换工具
NETWORK · HAR

HAR文件查看器

查看和分析HAR文件内容。

local
❯ har
drop a .har capture here — or click to browseDevTools → Network → right-click → “Save all as HAR”parsed in this tab · captures often hold cookies and tokens — they stay here
§01 关于此工具

概述

HAR 文件是浏览器加载过的一切内容的一份 JSON 记录,从 DevTools 导出。它非常精确,同时也几乎无法用肉眼阅读。这个查看器把它还原成你原本在 DevTools 里看到的那张瀑布图,于是你可以读懂别人发给你的抓包,而不必去打开他们的浏览器。

每条柱子都按浏览器实际记录下来的那些阶段拆开:在队列里被阻塞的时间、DNS、建立连接、TLS 握手、等待第一个字节,以及下载响应体。一条很长而且几乎全是 TTFB 的柱子说明这是服务器问题;一条很长而且几乎全是 download 的柱子说明这是负载体积问题。

使用方法

  1. 在 DevTools 里打开 Network,右键请求列表,选择 Save all as HAR
  2. 把文件拖到这里,或者点击浏览选择。没有任何东西会离开这个页面。
  3. 按资源类型过滤,点某一行看它的 URL 和完整的阶段拆分。
  4. TRANSFER BY TYPE,找出真正主导页面重量的到底是什么。

读懂各个阶段

这六段都是浏览器记录下来的,不是推导出来的,而且每一段都指向问题的不同责任方。

阶段衡量什么它变长时该找谁
blocked在浏览器里排队,等一个连接槽位页面自身——并发请求太多,或者还在用 HTTP/1.1
dns域名解析DNS 服务商,或者首次访问时的冷缓存
connectTCP 握手到源站的网络距离
tlsTLS 握手证书链长度,或者没有会话复用
ttfb请求发出之后的等待服务器。几乎总是应用或数据库耗掉的时间
download接收响应体负载大小,或者带宽

值为 -1 表示浏览器没有记录这个阶段,这是正常现象:一个复用已有连接的请求,根本就没有 dnsconnecttls 可言。工具会把这些段省略掉,而不是把它们画成零。

有两种形态值得练出条件反射。第一种是某一行 blocked 占了主导,而且很多行共用同一个主机——这是连接争用,解法是减少请求数或者上 HTTP/2,而不是换一台更快的服务器。第二种是文档请求那一行 ttfb 占了主导,这意味着抓包里其他每一条柱子都起步很晚;下游任何东西都不可能比那个数字更快。

读懂瀑布图的形状

每条柱子的水平位置和它的宽度一样重要。所有请求都被放在同一条时间轴上,所以出现阶梯状就意味着串行化:每个请求都要等前一个结束才能开始。常见的原因是阻塞渲染的样式表、阻塞解析器的同步脚本,或者一个 JSON 响应里装着下一轮请求所需要的 URL。

DCLLOAD 这两条标记来自抓包自带的页面耗时。落在 LOAD 右边的请求没有影响 load 事件——懒加载图片、分析信标、预取都属于这一类。落在 DCL 左边的请求则在关键路径上,无论你原本是不是这么打算的。

屏幕上被遮蔽的内容

查看器会把请求头和参数的值显示出来,好让你拿它们去排查问题,只有一个例外:名字看起来像凭据的那些值——CookieAuthorizationtokenapi_keysignaturecodestate——会以遮蔽形式显示。那只是一道防人从旁边看屏幕的措施,不是安全边界。你磁盘上的那个文件没有任何改动,里面每一个机密都还在原处。

如果你需要一份能附到 issue 上、或者能发给厂商的版本,请用 HAR 清洗器。它会真正重写 JSON——清空 cookie 数组、请求体和响应体、重定向目标以及 WebSocket 帧——然后交给你一份可以安全分享的文件。

示例

  • 首屏渲染慢: 在文档请求上找那一段特别宽的 TTFB——代价出在服务器身上,而不是网络身上。
  • 页面过重: 传输统计条通常一眼就能让人看出来,大部分字节到底是图片吃掉的,还是某一个 JS 包吃掉的。
  • 发布出错: 过滤到 js,找那些由陈旧引用残留下来的 404。
  • 一个你早就忘掉的第三方: 在传输量拆分里按主机排序。标签管理器往往会拉进来比当初添加它的那个人所预想的更多的东西。
  • 「我这里很快,用户那里很慢」: 拿他们的抓包和你自己的对比。dnsconnect 上的差异来自地理位置;同一个端点上 ttfb 的差异通常来自缓存状态。

说明

大小优先取抓包里记录的传输大小,如果没有就退回到响应体加请求头,再退回到解码之后的内容大小——顺序之所以这样安排,是因为不同的导出工具填充的字段并不一样。

资源类型先按 URL 的扩展名推断,其次才按 MIME 类型推断,因为即使某个请求本该返回的是脚本,出错页面照样会返回 text/html

不同浏览器导出的抓包不能直接互相比较。Firefox 和 Safari 填充的可选字段各不相同,Chrome 还会额外加上非标准的 _initiator_webSocketMessages 条目。这个查看器只读标准字段并忽略其余部分,所以一份 Firefox 的抓包会渲染得细节少一些,而不是直接失败。

如果你手上没有现成的抓包,load sample capture 会打开一份很小的合成 HAR,让你看看这个面板读起来是什么样子。那是演示数据,在头部有明确标注——不是真实的测量结果。

FAQ
我的抓包会被上传到什么地方吗?
不会。文件通过浏览器的 FileReader 读取,在页面内解析,不会发送到任何服务器。这一点在这里比平常更要紧——HAR 抓包里常常包含 Cookie、Authorization 头和会话令牌。
每条柱子上的颜色分别代表什么?
它们就是该请求的 HAR 耗时字段,按先后顺序是 blocked、dns、connect、tls、ttfb(wait)和 download(receive)。每一段的宽度是记录下来的实际值占这个请求总时间的比例,不是估算出来的。
为什么有的请求没有大小,或者显示「cache」?
HAR 只在浏览器确实知道传输大小时才记录它。从 HTTP 缓存命中的请求在网络上没有传输任何字节,所以工具显示「cache」,而不是凭空编一个数字出来。
DCL 和 LOAD 这两条线是从哪里来的?
来自抓包自带的页面耗时(onContentLoad 和 onLoad)。如果这份 HAR 没有 pages 段——有些导出工具会省略它——那么这两条标记线就干脆不画。
在这里看过之后,抓包可以直接分享出去吗?
原样不行。这个查看器只在屏幕上遮蔽机密,并不改动文件本身。请先用 [HAR 清洗器](/zh/har-sanitizer/) 过一遍,它会重写 JSON,交给你一份可以安全附加的版本。