Chrome Recorder 不直接测量动作延迟，需配合 Performance 面板二次录制分析；先用 Recorder 录制交互链路，再回放时同步启用 Performance 面板抓取真实 JS 延迟，并通过时间轴交叉验证关键动作性能瓶颈。
Chrome Recorder 本身不直接测量或输出每个动作的原始延迟（比如“点击按钮耗时多少毫秒”），它专注记录操作序列并支持回放；要获取每个动作的真实延迟，必须配合 Performance 面板做二次录制分析——这是目前 Chrome 官方链路中最可靠、零依赖外部工具的方案。
一、先用 Recorder 录制标准交互链路
确保 Chrome 版本 ≥ 117，且已启用 chrome://flags/#enable-devtools-recorder 并重启浏览器。打开目标页面后：
- 按 Ctrl+Shift+I（Win/Linux）或 Cmd+Option+I（macOS）唤出 DevTools
- 点击右上角 ⋯ → More tools → Recorder，或找工具栏中“播放键+圆点”图标
- 点 + New recording，给任务命名（如“搜索-点击-展开详情”），再点 Start recording
- 在页面中完成你要分析的高频操作（例如：输入关键词 → 点搜索按钮 → 等列表加载 → 点第一条 → 滚动到底部 → 点“加载更多”），全程不新开标签页
- 结束后点 Stop recording，保存流程
二、回放时同步启动 Performance 面板抓取真实延迟
Recorder 回放本身不带计时，但你可以让它“驱动”Performance 面板捕获每一步背后的耗时细节：
- 保持 DevTools 打开，切换到 Performance 面板
- 勾选 Screenshots（可选，用于对齐视觉反馈）、Memory、Network
- 点击左上角圆形 Record 按钮开始监听
- 立刻切回 Recorder 面板，点击刚录好的流程右侧的 Replay 按钮（推荐选“慢速”或“非常慢”，便于对齐时间轴）
- 等回放结束，立即在 Performance 面板点 Stop，等待分析完成
此时时间轴里每一帧、每一个 Layout/Script/Paint 事件都对应着你录制中的某次点击或输入。把鼠标悬停在黄色（Scripting）长条上，就能看到具体执行了哪个事件监听器、耗时多少毫秒——这就是该动作触发的真实 JS 延迟。
三、定位关键动作延迟的实操技巧
高频链路常卡在异步时机，仅看 Recorder 步骤名不够，需结合 Performance 时间轴交叉验证：
- 导航后白屏？ 查看 Network 轨道中 HTML 加载完成时间，再看下一帧 Rendering 是否滞后 —— 若间隔 > 100ms，说明路由跳转后 JS 初始化慢
- 点击无响应？ 在时间轴中找到该 click 事件（可通过 Console 打印 log 或断点辅助定位），看后续是否出现 Forced Synchronous Layout（紫色警告图标）或长任务阻塞
- 输入卡顿？ 输入框 focus 后观察 scripting 轨道是否频繁触发 input/change 监听器；若单次执行 > 16ms（1帧），就会掉帧
- 滚动不流畅？ 切换到 Rendering 子面板，开启 FPS meter，回放时观察是否跌破 60fps；再查 Painting 轨道是否存在大面积重绘
四、导出数据用于横向对比（比如不同网络环境）
Recorder + Performance 组合支持可复现的基准测试：
- 用同一份 Recorder 脚本，在不同网络条件（如 3G、4G、禁用缓存）下重复回放 + Performance 录制
- 导出每次的 Performance JSON（右键 Summary 区域 → Save profile）
- 用文本比对工具查看关键指标差异：如 First Contentful Paint、Scripting 总耗时、最大长任务时长
- 若需自动化，可将 Recorder 导出为 Puppeteer 脚本（Recorder → ⋯ → Export → Puppeteer），再注入
performance.mark()和performance.measure()手动埋点
这套方法不依赖第三方插件，全部基于 Chrome 内置能力，能准确反映用户真实操作路径中每个原子动作的性能代价。
