外观
线上页面变慢，你怎么查？
先把现象说具体，再测量，只改一处，然后用同一种方式复测。答案按「现象、指标、定位、改动、复测」来说，不要先背优化清单。
原理
- 现象。 哪一页、什么操作、什么设备。第一次打开慢，还是点了某个筛选才慢。能不能稳定复现。
- 指标。 加载用瀑布图看 DNS、连接、TTFB、下载。体验用 LCP、INP、CLS。交互卡顿看性能面板里的长任务。见 Core Web Vitals。
- 定位。 对上时间花在哪：
- TTFB 长：服务器、接口或网络，不是组件。
- 下载长：某个 JS、图片或字体太大，或者缓存没生效。
- 主线程长任务：脚本执行、大列表渲染、同步布局。
- React 用 Profiler 看是哪个组件在反复渲染；调用栈能看出是哪一个事件处理函数。
- 改动。 一次只动瓶颈最大的那一项。加载问题见 加载优化，渲染问题见 渲染优化。
- 复测。 用同设备、同网络条件再记一次数字。实验室数据和真实用户数据分开报。
讲项目时准备一个自己做过的例子：当时的数字、你看了哪张面板、改了什么、之后的数字。没有数字的「我优化了性能」站不住。
追问
本地很快，用户很慢，怎么解释？
本地通常是好机器、空缓存策略不同、接口很近。先要一份现场记录：设备、网络、地理、是哪一个资源慢。再用限速和低端 CPU 在本地复现，而不是在自己的机器上反复刷新。
第三方脚本拖慢了页面？
把它从关键路径拿开：延迟加载、放到 Web Worker（如果它支持）、或者在交互之后再插入。用瀑布图指出它挡了哪个 LCP 资源。
易错点
- 一上来就上虚拟列表或换框架。瓶颈可能是一张 3MB 的图。
- 只看 Lighthouse 总分。总分下降可能是无关项，业务上要看的是那一项指标。
- 在开着一堆扩展的浏览器里录性能，长任务里混进了扩展的时间。