你做过哪些性能优化，怎么证明有效
先理解原理和示例，再练习完整口述与追问。
回答要点
按“用户问题 → 基线指标 → 工具定位 → 根因 → 改动 → 同条件对比 → 回归”讲。区分实验室数据和真实用户数据，明确设备、网络、缓存状态、样本和分位数，不能只报 Lighthouse 分数。
Core Web Vitals 当前包括 LCP、INP、CLS；良好阈值分别是 ≤ 2.5s、≤ 200ms、≤ 0.1，按移动端 / 桌面端分别看第 75 百分位。INP 不等于首屏时间。web.dev：Web Vitals
原理拆解
先定义性能问题和基线：首屏、输入响应、滚动、内存或接口等待。使用真实用户分布与可控实验互补，指标按分位数、设备和网络分组，避免平均值掩盖尾部体验。当前 Core Web Vitals 主要关注 LCP、INP、CLS；具体阈值与统计口径应按采用规范核实。
示例与推演
同一设备与数据量下，记录优化前后的网络瀑布、长任务、LCP 和交互耗时。若大表格优化为虚拟列表，比较滚动掉帧和 DOM 数量，同时检查总内存、焦点、选中与定位功能。没有线上数据时，明确说明这是实验室结果，不能包装成全量用户收益。
易错点
不要只报 Lighthouse 总分，也不要把开发模式性能当生产结论。优化一项可能损害另一项，例如预加载过多资源会争抢带宽。
参考回答可直接练习口述
如果问已做过的优化，我只报告自己实际测过的案例；没有数据就说明没有。完整表达应是：用户在哪个场景慢，我如何记录设备、网络、缓存和指标，用什么工具找到瓶颈，修改哪一项，再在相同口径下比较。LCP 看主要内容加载，INP 看交互响应，CLS 看布局稳定性；良好阈值分别不高于 2.5 秒、200 毫秒和 0.1，按移动端与桌面端分别看第 75 百分位。单次 Lighthouse 分数不能替代真实用户结论。