DevTools Performance 面板
Performance 面板用于录制页面加载和交互过程，分析主线程任务、布局、绘制、长任务和体验指标。
#concept
#growing
#frontend
#browser
#chrome-devtools
[!info] related notes
- 所属 MOC: 浏览器开发者工具 MOC, DevTools Performance MOC, 前端性能优化 MOC
- 前置概念: 浏览器渲染过程, 性能指标体系, INP
- 并列概念: Network 面板, Memory 面板, Rendering 面板
- 易混淆概念: 性能监控体系
- 关系笔记: 浏览器开发者工具
DevTools Performance 面板
一句话定义
Performance 面板用时间轴回答“页面为什么慢、卡、掉帧”。
核心内容
它最适合回答什么问题
- 页面加载慢，慢在资源、脚本还是渲染
- 某次点击或滚动为什么卡顿
- 哪些任务阻塞了主线程
- Layout、Paint、Composite 的代价在哪里
- LCP、CLS、INP 一类问题在录制里发生在哪个阶段
录制后重点看什么
- Main thread flame chart：主线程忙了什么
- Long task：超过帧预算的任务
- Screenshots：界面在时间线上如何变化
- Network track：资源加载与 CPU 工作如何重叠
- Layout shifts / Web Vitals 轨道：体验问题发生点
继续往下拆
常见使用场景
- 页面首屏慢
- 输入、点击、切换 Tab 之后明显卡顿
- 动画掉帧
- Hydration、列表渲染、图表绘制成本过高
一个实用排障顺序
- 录制真实操作，不要只看空闲页面
- 先找时间线上最明显的长任务
- 判断是脚本、布局、绘制还是资源等待
- 再回到 Sources 面板 或 Network 面板 定位根因
边界与易混淆点
- Performance 是实验室分析工具，不等于线上真实用户监控
- 录制结果很依赖操作路径，错误场景没录进去就看不到问题
- 只看总时长不够，要看任务结构和关键阻塞点
学习检查
- Performance 面板最适合回答“时间花在哪里”，为什么不能直接回答所有业务根因？
- Main thread、Network、Frames、Screenshots、Timings 各自提供哪一类证据？
- Long Task、Layout、Paint、LCP、INP 之间是什么关系，但为什么不能简单一一对应？
- 为什么录制路径必须尽量复现真实用户操作？
- CPU/Network throttling 改变的是实验条件还是生产事实？
- 给一个“点击后卡 800ms”的案例，说明如何从录制定位到脚本、布局或绘制中的主导成本。
Digital Biome