性能优化先描述用户遇到了什么：主要内容出现太晚、点击后没有反馈，还是页面突然移动。只盯一个总分，容易优化了不影响当前问题的部分。
指标和场景对应
Core Web Vitals 目前关注 LCP、INP、CLS，分别反映主要内容加载、交互响应和视觉稳定性。当前“良好”阈值分别为 LCP 不超过 2.5 秒、INP 不超过 200 毫秒、CLS 不超过 0.1；真实用户统计还要看相应分位和访问条件。它们不是一台开发机跑一次就能得出的站点结论。
实验室测量用于复现和诊断，真实用户数据反映实际设备、网络、缓存和行为分布。实验里没有进行交互，就不能拿它推断完整的 INP；开发者工具录屏也不能代替长期用户数据。
一次可重复的排查
- 写明路由、数据规模、动作、浏览器、设备与网络条件，使用生产构建。
- 在 Network 查看关键资源和请求依赖，在 Performance 录制问题动作。
- 找到耗时最大的具体工作：脚本、样式布局、图片、网络等待或第三方代码。
- 一次改变一个主要因素，重跑相同条件并保留前后记录。
- 同时检查功能、内存、画质和可访问性，避免把工作转移成另一种成本。
例如一个卡片列表初次加载慢：若大图请求开始太晚，先查发现时机；若下载快但解码、渲染重，先查尺寸与页面数量；若包下载后长时间执行，才需要进一步拆脚本。把所有图片都设成懒加载，可能反而推迟首屏重要图片。
performance.mark("filter:start");
const result = records.filter(item => item.title.includes(query));
performance.mark("filter:end");
performance.measure("filter", "filter:start", "filter:end");
// records、query 由应用提供；这个区间只测过滤计算。
这是局部测量片段，不包括 DOM 更新和绘制。频繁测量要清理不需要的 marks/measures，统计时注明样本量。一次 0 毫秒可能只是分辨率与工作量的结果，不能证明没有成本。
常见取舍
虚拟列表减少挂载节点，但影响搜索、焦点和动态高度处理；缓存减少重复计算，但要管理失效与内存；预加载提前工作，但可能争抢关键带宽；Worker 减少主线程计算，但有通信成本。React memo、Vue computed 等也需围绕真实更新路径使用。
内存问题检查对象是否仍被定时器、订阅、缓存或 DOM 引用。重复进入退出页面，观察堆快照和保留路径；一次堆增长可能来自合理缓存，不能直接宣布泄漏。
练习：用渲染实验页制作一份排查记录，写出假设、测量范围、修改、前后结果与仍未测到的部分。不能填写未实际获得的数字。