技能介绍

页面加载慢，到底是哪一段在拖后腿

把 Performance 面板截图发到群里，得到的通常是「首屏 3 秒，有点慢」。但 3 秒花在哪儿：DNS 查询、TCP 建连、SSL 握手、TTFB，还是资源下载？不同原因对应完全不同的修法——TTFB 高要去查后端和 CDN，DNS/SSL 开销高要减少域名数量或加 preconnect，下载时间长则是资源体积问题。只看面板上的一两个聚合数字，很难定位到具体请求和具体阶段。

浏览器 DevTools 的 Network 面板其实导出了完整的请求日志（HAR）。它记录了每个请求的逐阶段耗时、状态码、响应大小、MIME 类型和发起者，只是没人去逐项翻。@user_b30f8db8/har-performance-analyzer 就是做这件事的：解析 HAR JSON，把聚合指标拆到单个请求，再按优先级输出能直接执行的优化建议。

它是怎么做的

从 Chrome/Firefox/Edge DevTools 的 Network 面板导出 HAR，建议勾选保留日志、禁用缓存以反映真实冷加载
运行内置 Python 脚本 scripts/analyze_har.py，支持 --top N 控制榜单长度、--domain 指定主域名、--json 输出结构化数据、--html 生成自包含报告
查看报告：摘要卡片（带颜色分级）、资源类型分布、时序瀑布图、响应时间直方图、可排序的 Top 慢请求与 Top 大资源表、自有域名 vs 第三方域名拆解

报告不只是罗列数据，还会给出具体判断：哪些 JS/CSS 阻塞了解析、哪些资源缺少正确的缓存头、哪些请求的建连开销异常、第三方脚本占了多大比重，最后汇总成按严重等级排序的操作清单。常见方向包括延迟非关键脚本（async / defer）、内联关键 CSS、代码分割、WebP/AVIF 与 srcset、Cache-Control: max-age=31536000 等，具体采用哪条取决于你的 HAR 里哪一项超标。

注意边界

超大 HAR（>100MB）：脚本在内存中处理全部条目，导出前最好先在 DevTools 里过滤到单次页面加载
缺少 pageTimings：部分导出没有页面级时间戳，脚本会退化为条目级分析
编码响应体：content.text 里的 base64 内容默认不解码，大小分析以响应头中的 bodySize 为准
阈值是参考值：TTFB 500ms、DOMContentLoaded 3s、onLoad 5s、单请求 1s、页面总大小 5MB，用来给报告定级，但最终取舍仍要看业务

结论一句话：下次页面慢，别急着猜，把 HAR 丢进来跑一遍。