用 HAR 文件做网页性能分析, 找出加载瓶颈

页面感觉慢, 但说不清慢在哪里。这是前端排查最常见的起点。打开监控大盘前, 其实浏览器自己就记录了答案, 它藏在一个叫 HAR 的文件里。

HAR 文件到底记了什么

HAR 是 HTTP Archive 的缩写, 本质是一个 JSON 文件。它把浏览器 Network 面板里发生的一切都序列化了下来: 每个请求的 URL、响应状态码、开始时间、各阶段耗时 (DNS、连接、等待、下载)、响应头、内容体积, 以及页面元信息。

换句话说, 一次页面加载里发了多少个请求, 哪个请求卡了多久, 哪个资源体积最大, HAR 里全都有。它不是截图, 而是结构化的原始数据, 这意味着可以被工具读取、排序、汇总, 而不是靠肉眼数瀑布流。

从 DevTools 导出一份 HAR

在 Chrome 或 Edge 里按 F12 打开开发者工具, 切到 Network 面板。导出前建议勾上 Preserve log, 这样跳转和刷新都不会清空记录。然后正常加载一次你要排查的页面。

加载完成后, 在请求列表上右键, 选择 Save all as HAR with content, 或者点面板里的下载图标。Firefox 的入口类似, 在 Network 面板右键导出。你会得到一个 .har 文件, 它可能有几 MB 甚至几十 MB, 取决于页面有多少请求。

先看最慢请求和最大资源

拿到 HAR 之后, 不要从头读到尾, 那样会淹没在几百行请求里。正确的顺序是先抓两类目标。

第一类是最慢请求。把所有请求按总耗时倒序排, 排在最前面的就是阻塞页面的元凶。它可能是一个没走 CDN 的接口, 也可能是一个等待时间 (TTFB) 异常高的后端响应。

第二类是最大资源。按响应正文体积倒序排, 超过 500 KB 的资源要重点看, 尤其是图片和 JS bundle。一张没压缩的首屏大图, 往往比十个小接口加起来还拖慢加载。

定位这两类目标, 基本就锁定了八成的瓶颈。剩下的再看失败请求 (4xx/5xx)、第三方主机数量、静态资源缓存头是否偏弱。

一个真实的排查例子

上周我帮一个落地页排查首屏慢的问题。页面看着不复杂, 但首屏要等三四秒。我导出 HAR, 用 HAR 性能分析器 跑了一遍, 报告里最慢请求那一栏第一行特别扎眼: 一个 hero 区域的背景图, 单个请求耗时 2.8 秒, 体积 3.1 MB, 几乎等于整个页面其余资源之和。

原因很简单, 设计稿直接导出了一张未压缩的 PNG, 没做任何尺寸适配。把它换成压缩后的 WebP, 首屏直接快了一倍多。如果只盯着代码看, 我可能会怀疑是接口慢、是渲染卡, 绕一大圈也找不到这张图。HAR 把它排在了最显眼的位置, 省掉了所有猜测。

为什么一定要在本地分析

这里有一条容易被忽略的安全红线: HAR 文件可能包含敏感信息。它记录的请求头里往往带着 cookie、Authorization token、内部 API 路径, 查询参数里也可能有用户 ID 或会话标识。

把这种文件传到一个在线 HAR 查看器, 等于把登录态拱手交给别人。所以分析必须在本地完成, 文件读取和计算都在浏览器页面里跑, 不上传到任何服务器。哪怕要把报告发给同事, 也要先检查里面有没有泄露主机名、私有路径或带 token 的 URL。

排查完性能, 如果你还想顺手体检站点的其他维度, 可以用 Sitemap URL 审计 检查站点地图里的链接是否都可达, 两个工具配合能覆盖加载性能和收录健康两条线。

小结

网页性能分析不需要一上来就堆监控系统。一份 DevTools 导出的 HAR, 加上一个本地分析工具, 先排最慢请求和最大资源, 再看失败请求与缓存, 大多数加载瓶颈都能在几分钟内定位。记住一点: HAR 含敏感数据, 永远在本地分析。

---

Made by Toolora · Updated 2026-06-13