首页 / 资讯中心 / 文章详情

sitespeed.io 文档详解 chrome-har:把 Chrome DevTools Protocol 事件流转换成 HAR 文件

sitespeed.io 文档详解 chrome-har:把 Chrome DevTools Protocol 事件流转换成 HAR 文件 ★ FEATURED ARTICLE
测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载chrome-har 是 sitespeed.io 生态中的独立工具型库它接收你自行捕获的 Chrome DevTools ProtocolCDP事件流输出符合 HAR 1.2 规范的文件。读完本文你能掌握harFromMessages的完整用法、两个可选参数磁盘缓存资源、响应体的含义与默认值、如何为 SPA 软导航拆分 HAR 页面以及 sitespeed.io 内部是如何消费 chrome-har 产出的 HAR 数据的存储插件、域名聚合器与真实 HAR 样例结构。定位与来历面向工具开发者的 HAR 生成库Chrome-HAR 的核心定位是给工具作者使用的库a library for tool makers你自己捕获 Chrome DevTools Protocol 的事件把事件数组交给 Chrome-HAR即可得到一个 HAR 文件。它最初是从 Browsertime 中抽取出来的——早期实现参考了 Chromedriver_har 的思路后来 sitespeed.io 团队把这部分能力独立成包方便其他项目直接复用见 历史发布说明 中对这次拆分的描述。两个对使用者重要的事实版本形态自 1.0.0 起 Chrome-HAR 是纯 ESM 包必须用import而不是require引入。当前版本sitespeed.io 仓库文档侧标注的 chrome-har 版本为1.3.1版本文件同时 npm-shrinkwrap.json 中锁定的依赖版本也是chrome-har1.3.1说明当前 sitespeed.io42.7.0通过 browsertime 28.3.0 间接依赖的正是这个版本。安装npm install chrome-har快速开始把 CDP 消息流转成 HAR核心 API 只有一个函数harFromMessages(messages)。messages是你收集到的 CDP 事件数组import { harFromMessages } from chrome-har; // messages is the array of Chrome DevTools Protocol events you have collected. const har harFromMessages(messages); // Do whatever you want with the HAR file.返回的har就是完整 HAR 对象包含log.pages页面级信息与pageTimings和log.entries每个请求的条目。可选参数OptionsharFromMessages(messages, options)接受第二个参数对象共有两个开关选项默认值作用includeResourcesFromDiskCachefalse是否把从 Chrome 磁盘缓存中命中的请求也写入 HARincludeTextFromResponseBodyfalse是否写入响应体。注意调用方有责任在把消息传入之前自行把body挂到 response 对象上做法见下节import { harFromMessages } from chrome-har; const har harFromMessages(messages, { includeResourcesFromDiskCache: true, includeTextFromResponseBody: true });响应体为什么需要拦截请求响应体并不在标准 CDP 事件Network.responseReceived的 payload 中因此默认流程拿不到 body。要把它写进 HAR需要三步拦截请求监听Network.requestIntercepted通过Network.getResponseBodyForInterception拉取 body并挂到params.response.body上用Network.continueInterceptedRequest恢复请求并把这条消息作为合成的Network.responseReceived事件推入事件数组最后以includeTextFromResponseBody: true调用harFromMessages。官方给出的完整示例const harEvents []; client.on(Network.requestIntercepted, async params { const response await client.send(Network.getResponseBodyForInterception, { interceptionId: params.interceptionId }); if (params.response ! null) { params.response.body response.body; } else { params.response response; } await client.send(Network.continueInterceptedRequest, { interceptionId: params.interceptionId }); harEvents.push({ method: Network.responseReceived, params }); }); const har harFromMessages(harEvents, { includeTextFromResponseBody: true });注意示例里对params.response的分支处理拦截事件里 response 可能已经存在此时只需补body也可能为null此时整体替换为getResponseBodyForInterception的返回两种情况都覆盖到了。软导航Soft NavigationSPA 路由切换也生成独立 HAR 页面单页应用的 hash/路由切换不会触发完整文档加载但 Chrome-HAR 支持把它们捕获为各自独立的 HAR 页面调用方在 Chrome 的PerformanceObserver报告发生软导航时主动推一条合成的SoftNavigation.detected消息并携带新 URLChrome-HAR 会据此切换当前页面。如果通过 Browsertime 运行这一步是自动完成的单独使用 Chrome-HAR 时你可以自行发出该事件messages.push({ method: SoftNavigation.detected, params: { url: https://example.com/route } });sitespeed.io 内部如何消费 chrome-har 的产物在 sitespeed.io 中chrome-har 并不是直接暴露给终端用户而是作为浏览器引擎链路的一部分工作sitespeed.io 的 browsertime 插件 通过BrowsertimeEnginebrowsertime 包驱动真实浏览器引擎内部使用 chrome-har 把 CDP 事件转成 HAR再以browsertime.har消息形式进入 sitespeed.io 的消息队列。仓库中可以看到几个佐证点HAR 存储插件harstorer 插件 监听browsertime.har消息把 HAR 序列化为 JSON 写入结果目录开启--gzipHAR后会把 JSON 流式压缩为.har.gz再落盘CLI 选项定义中可见该 boolean 选项默认false。大文件读取路径browsertime reader 中专门实现了流式 gunzip注释明确提到 Chrome traces and HARs are routinely 50 MB——这正是 HAR 作为重型产物在工具链中流转的实证。下游消费者domains 聚合器 直接从 HAR 条目的entry.timingsblocked/dns/connect/ssl/send/wait/receive和response._transferSize回退到bodySize计算各域名的请求量、总耗时与传输字节统计注释中也写明 Browsertime / chrome-har set_transferSize(compressed) when CDP delivered the value。真实 HAR 长什么样以仓库内置 fixture 为例test/fixtures/www-thegreenwebfoundation-org.har 就是一份由 chrome-har 生成的真实 HAR可以快速认识它的结构log.creator.name为chrome-harlog.version为1.2fixture 头部pages[0]带有非标准扩展字段_url被测 URL、_meta.connectivity如native以及pageTimings中的_firstPaint、_domInteractiveTime、_domContentLoadedTime等站点速度指标每个 entry 携带 chrome-har 的扩展字段_requestId、_initialPriority/_priority如VeryHigh、_requestTime、serverIPAddresstimings中除标准七段外还有_queuedresponse 中除标准content.size/content.compression外还有 chrome-har 特有的bodySize与_transferSize压缩后的线上字节数。从发布记录看这些扩展字段是持续演进的chrome-har 0.2.1 补充了serverIPAddress、正确的bodySize与_transferSize等见 CHANGELOG而 1.3.0 又为每个 entry 新增了_renderBlocking字段直接映射 Chrome 108 的 CDPrenderBlockingStatus让下游 HAR 消费者无需再从 trace 推断哪些资源阻塞了首次绘制见 chrome-har 发布 feed。报 Bug 时如何提供 CDP 事件轨迹当 HAR 缺少条目或内容异常时官方要求附上 CDP 事件轨迹以便复现。采集方式是给浏览器引擎打开 perflog 收集直接用 Browsertimebrowsertime --chrome.collectPerfLog -n 1 https://www.sitespeed.io用 sitespeed.iositespeed.io --browsertime.chrome.collectPerfLog -n 1 https://www.sitespeed.io需要附上的文件是chromePerflog-1.json.gz——把它附到 issue 或放到 gist 中共享。这套流程在 Bug 报告文档 的按 bug 类型采集对应证据表格中也被列为 Chrome HAR 类问题的标准做法--chrome.collectPerfLog→chromePerflog-1.json.gz。小结与适用前提chrome-har 的输入是你自己捕获的 CDP 事件数组它不负责连接浏览器、发起拦截拦截响应体getResponseBodyForInterception链路与 SPA 软导航事件的发射在独立使用时都由调用方完成。默认不含磁盘缓存命中与响应体两个开关按需开启开启includeTextFromResponseBody前必须先按上文方式把body挂到 response 上。在 sitespeed.io 语境下你通常不直接调用 chrome-har而是通过--gzipHAR控制 HAR 落盘形态、通过--browsertime.chrome.collectPerfLog收集排障轨迹再结合 HAR 存储插件 产出的browsertime.har(.gz)文件分析结果。版本前提本文描述基于当前仓库sitespeed.io 42.7.0对应的 chrome-har 1.3.1 行为且 1.0.0 起仅支持 ESM 导入方式。赞分享测试性能剖析指标监控【免费下载链接】sitespeed.iositespeed.io is an open-source tool for comprehensive web performance analysis, enabling you to test, monitor, and optimize your website’s speed using real browsers in various environments.项目地址https://gitcode.com/gh_mirrors/si/sitespeed.io点击查看免费下载相关推荐Chrome DevTools Protocol 技术文档Chrome DevTools Protocol 技术文档 1. 安装指南 1.1 通过 npm 安装 要安装 devtools protocol 模块请在终开发工具高效解析HAR文件har-extractor开源工具推荐高效解析HAR文件har extractor开源工具推荐 项目介绍 har extractor 是一个强大的命令行工具专门用于将HTTP Archive H开发工具CLI创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站