trace-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Chrome DevTools Trace Audit

Chrome DevTools 性能追踪审计

Analyze a Chrome DevTools Performance trace and produce a comprehensive performance audit report.

分析Chrome DevTools性能追踪文件并生成全面的性能审计报告。

Usage

使用方法

/trace-audit <path-to-trace.json>

The argument is the absolute path to a Chrome DevTools trace JSON file (exported from the Performance panel).

/trace-audit <path-to-trace.json>

参数为从Performance面板导出的Chrome DevTools追踪JSON文件的绝对路径。

Workflow

工作流程

Follow these steps in order. Use parallel tool calls wherever noted.

按顺序执行以下步骤，注意在标注处使用并行工具调用。

Step 1 — Validate the trace file

步骤1 — 验证追踪文件

Read the first 100 lines of the file using the Read tool. Confirm it is a valid Chrome DevTools trace by checking for:

A top-level
```
traceEvents
```
array, or a bare JSON array starting with
```
[
```
Event objects with
```
name
```
,
```
cat
```
,
```
ph
```
,
```
ts
```
fields
Presence of
```
__metadata
```
or
```
TracingStartedInBrowser
```
events

If validation fails, tell the user this doesn't appear to be a Chrome DevTools trace and stop.

使用Read工具读取文件的前100行。通过以下检查确认其为有效的Chrome DevTools追踪文件：

顶级的
```
traceEvents
```
数组，或以
```
[
```
开头的裸JSON数组
包含
```
name
```
、
```
cat
```
、
```
ph
```
、
```
ts
```
字段的事件对象
存在
```
__metadata
```
或
```
TracingStartedInBrowser
```
事件

如果验证失败，告知用户这似乎不是Chrome DevTools追踪文件并停止操作。

Step 2 — Extract metadata

步骤2 — 提取元数据

Use Grep on the trace file to extract (run these in parallel):

Site URL — grep for

TracingStartedInBrowser

navigationStart

FrameCommittedInBrowser

and look for a URL in the

args

Process names — grep for
```
process_name
```
or
```
thread_name
```
to identify renderer, browser, GPU processes
Trace time range — grep for the first and last
```
"ts":
```
values to compute trace duration

使用Grep工具对追踪文件执行以下并行提取操作：

站点URL — 搜索

TracingStartedInBrowser

、

navigationStart

或

FrameCommittedInBrowser

，并在

args

字段中查找URL

进程名称 — 搜索
```
process_name
```
或
```
thread_name
```
以识别渲染进程、浏览器进程、GPU进程
追踪时间范围 — 搜索第一个和最后一个
```
"ts":
```
值以计算追踪时长

Step 3 — Run detection passes

步骤3 — 运行检测流程

Refer to

detection-heuristics.md

for the full set of patterns and thresholds. Run all detection categories in parallel using Grep. For each category:

Use the specified grep pattern on the trace file
Collect matching lines with surrounding context where helpful (
```
-C 1
```
or
```
-C 2
```
)
Count matches and extract durations/values from the matched JSON

The detection categories are:

Long Tasks (
```
RunTask
```
with dur > 50000)
Layout Thrashing (
```
InvalidateLayout
```
→
```
Layout
```
pairs)
Forced Reflows (
```
Layout
```
events with
```
stackTrace
```
)
rAF Ticker Loops (
```
RequestAnimationFrame
```
frequency)
Style Recalc Storms (
```
UpdateLayoutTree
```
with dur > 5000)
Paint Storms (
```
Paint
```
events with dur > 3000)
GC Pressure (
```
MajorGC
```
/
```
V8.GC_MARK_COMPACTOR
```
)
CLS (
```
LayoutShift
```
cumulative score)
INP (
```
EventTiming
```
max duration)
Network Errors (
```
ResourceReceiveResponse
```
with statusCode >= 400)
Redundant Fetches (same URL fetched multiple times)
Script Eval (
```
EvaluateScript
```
/
```
CompileScript
```
with dur > 50000)
Long Animation Frames (
```
LoAF
```
/
```
LongAnimationFrame
```
)

参考

detection-heuristics.md

中的完整模式和阈值。使用Grep工具并行运行所有检测分类。对于每个分类：

对追踪文件使用指定的grep模式
收集匹配行及相关上下文（可使用
```
-C 1
```
或
```
-C 2
```
参数）
统计匹配数量并从匹配的JSON中提取时长/数值

检测分类包括：

Long Tasks（时长>50000的
```
RunTask
```
事件）
Layout Thrashing（
```
InvalidateLayout
```
→
```
Layout
```
事件对）
Forced Reflows（带有
```
stackTrace
```
的
```
Layout
```
事件）
rAF Ticker Loops（
```
RequestAnimationFrame
```
触发频率）
Style Recalc Storms（时长>5000的
```
UpdateLayoutTree
```
事件）
Paint Storms（时长>3000的
```
Paint
```
事件）
GC Pressure（
```
MajorGC
```
/
```
V8.GC_MARK_COMPACTOR
```
事件）
CLS（
```
LayoutShift
```
累积分数）
INP（
```
EventTiming
```
最大时长）
Network Errors（状态码≥400的
```
ResourceReceiveResponse
```
事件）
Redundant Fetches（同一URL被多次请求）
Script Eval（时长>50000的
```
EvaluateScript
```
/
```
CompileScript
```
事件）
Long Animation Frames（
```
LoAF
```
/
```
LongAnimationFrame
```
事件）

Step 4 — Aggregate findings

步骤4 — 汇总检测结果

For each detection category:

Compute total count of flagged events
Extract the worst offender (max duration or highest score)
Classify severity: Critical (red) or Warning (yellow) based on the thresholds in
```
detection-heuristics.md
```
Skip categories with zero findings

针对每个检测分类：

计算标记事件的总数
提取最严重的违规项（最长时长或最高分数）
根据
```
detection-heuristics.md
```
中的阈值将严重性分类为Critical（严重）或Warning（警告）
跳过无检测结果的分类

Step 5 — Identify timeline hotspots

步骤5 — 识别时间线热点

Group flagged events by timestamp into time windows (e.g., 500ms buckets). Identify windows where multiple issue categories overlap — these are hotspot ranges that represent the most problematic sections of the trace.

按时间戳将标记事件分组到时间窗口（如500ms桶）。识别存在多个问题分类重叠的窗口——这些是热点区间，代表追踪记录中问题最突出的部分。

Step 6 — Generate report

步骤6 — 生成报告

Output the report using the structure defined in

report-format.md

. The report should be:

Actionable — every issue links to a concrete fix
Scannable — use tables, severity badges, and clear headings
Complete — cover all categories, even if just to say "no issues found"

使用

report-format.md

中定义的结构输出报告。报告需满足：

可执行性——每个问题都关联具体的修复方案
易读性——使用表格、严重性标识和清晰的标题
完整性——覆盖所有分类，即使仅说明“未发现问题”