运行时性能优化的核心是“测得到、看得懂、改得准”，需用chrome devtools带着问题录制、聚焦主线程火焰图，紧盯fcp
直接上手分析，别先背理论。运行时性能优化的核心是“测得到、看得懂、改得准”，重点不是知道指标叫什么，而是清楚它在你当前页面里意味着什么。
用对工具，别只点录制按钮
Chrome DevTools 的 Performance 面板不是“点一下→看报告”就完事。要带着问题录：
- 点击某个按钮后卡顿？那就只操作这一个动作，关闭其他标签页，避免干扰
- 滚动不流畅？开启“Screenshots”选项，看帧率是否稳定在 60fps
- 首屏加载慢？勾选“Network”和“JS Profile”，确认是脚本下载阻塞，还是执行耗时过长
录完后重点看主线程（Main）的火焰图：红色长条是高耗时任务，黄色是渲染相关，蓝色是 JS 执行。拖选一段卡顿区域，右键 → “Zoom to selection”，再点进去看具体函数调用栈。
盯住四个关键指标，不贪多
不用记全部 Web Vitals，日常开发盯紧这四个就行：
- FCP ：首次有内容出现的时间。如果超了，优先检查是否阻塞渲染的 JS/CSS（比如没加
async或defer的大脚本） - TTI ：页面真正可交互的时间。常见拖慢原因：长任务（>50ms）、未拆分的初始化逻辑、大量同步 DOM 操作
- CLS ：布局偏移得分。典型场景：图片没设宽高、广告位异步插入、字体加载导致重排
- 内存占用 ：在 Memory 面板拍堆快照（Heap Snapshot），对比操作前后，看哪些对象没被释放（比如事件监听器没解绑、闭包持有大数组）
从代码到行为，建立因果链
看到一个 200ms 的 JS 任务，别急着重写函数。按顺序问自己：
- 这个任务是哪次用户操作触发的？（例如：点击“加载更多”）
- 它做了什么？是计算、DOM 更新、还是数据处理？
- 有没有重复执行？（比如 scroll 事件里没节流，每像素都跑一遍）
- 能不能延后或拆分？（用
setTimeout、queueMicrotask或requestIdleCallback）
比如循环插入 1000 个元素，火焰图显示 appendChild 占比高，那问题不在循环本身，而在每次插入都触发回流——换成 DocumentFragment 或字符串拼接，就能立竿见影。
养成测量习惯，而不是等出问题
在关键路径加轻量埋点，不需要第三方库：
- 用
performance.now()包裹核心函数 - 用
console.time('init')/console.timeEnd('init')快速验证模块耗时 - 在 CI 流程中跑 Lighthouse，把 FCP/TTI 设为门禁阈值（比如 FCP > 1500ms 就失败）
真正的复习不是反复看文档，而是每周挑一个已上线页面，用上面方法跑一次完整分析，输出一条可落地的优化建议（哪怕只是给一张图片补上 width 和 height）。
