Loading、Scripting等阶段耗时计算及Chrome Performance数值不符咨询

一、核心计算逻辑 #

Summary面板的分类耗时不是对应事件时长的简单累加，核心规则如下：

• 去重重叠事件：若同类别事件在时间轴上重叠，仅计算一次重叠区间时长，不会重复累加。比如两个并行执行的Scripting事件，重叠部分只统计一次。
• 排除Idle时段：所有分类耗时仅统计浏览器处于非空闲状态的时段，Idle状态的时间不会计入任何分类。
• 精确的事件分类映射：每个事件的归类严格遵循Chrome内部定义：
  • Loading：对应ResourceSendRequest、ResourceFinish等资源加载相关事件，但只统计资源加载过程中浏览器实际处理的时间，排除等待服务器响应的空耗时间。
  • Scripting：包含v8.compile、EventDispatch、FunctionCall等事件，但会剔除属于Rendering/Painting范畴的脚本执行（比如触发布局的脚本）。
  • Rendering：对应Layout、RecalculateStyle等布局与样式计算事件。
  • Painting：对应Paint、CompositeLayers等图层绘制与合成事件。
• 跨分类事件的归属：部分事件涉及多分类时，会按核心行为归类，比如触发布局的脚本执行会被计入Rendering而非Scripting。

二、手动计算不匹配的常见原因 #

• 未处理事件重叠，重复累加了重叠时段的时长。
• 错误映射事件分类，比如将Idle时段计入某类，或是把跨分类事件归错了类别。
• 忽略了Chrome对事件“有效时间”的计算：部分异步事件仅统计实际占用线程的时间，而非从触发到完成的全时段。

三、程序化获取的方法 #

通过Chrome DevTools Protocol（CDP）获取 #

1. 启动Chrome时添加参数--remote-debugging-port=9222开启调试端口。
2. 调用Performance.enable()开启性能监控，指定需跟踪的事件类别。
3. 调用Performance.start()开始记录，执行目标操作后调用Performance.stop()。
4. 通过Performance.getMetrics()直接获取预计算好的各类别耗时，该接口已处理好事件重叠与分类规则，结果与DevTools面板完全一致。

通过tracing库解析跟踪文件 #

在Node.js环境下使用Chrome官方tracing库解析.trace文件，自动遵循内部计算规则：

const tracing = require('tracing');
const traceData = require('./your-trace-file.json');
const model = new tracing.Model();
model.parse(traceData);
// 获取各类别汇总耗时
const summary = model.getSummary();
console.log('Loading:', summary.loading);
console.log('Scripting:', summary.scripting);
console.log('Rendering:', summary.rendering);
console.log('Painting:', summary.painting);

内容的提问来源于stack exchange，提问作者Shivam Mishra