标准答案
- Lighthouse 更适合做可重复的实验室检查，能发现资源阻塞、图片、缓存、可访问性和最佳实践问题。
- Web Vitals 更关注真实用户体验，核心指标包括 LCP、INP、CLS，通常要结合 RUM 或 CrUX 看趋势。
- 建立基线时要固定页面、设备档位、网络条件、运行次数和统计口径，避免一次分数波动误导判断。
- 性能预算可以限制首屏 JS、图片体积、LCP 时间、CLS、长任务和关键接口耗时。
- 发布后要比较新旧版本趋势，性能基线的价值在于发现回退，而不是追求一次满分。
题目解析
Lighthouse 分数有用，但不能单独代表真实用户体验。它是在受控环境里模拟加载，更适合找明显问题和做趋势比较；真实用户的网络、设备、地域和缓存状态会更复杂。
Web Vitals 基线应该看分布和趋势。比如 p75 LCP 是否超过阈值，INP 是否在某次发布后变差，CLS 是否集中出现在某个路由或设备上。
基线必须固定口径。页面、网络、设备、运行次数、是否登录、是否命中缓存都会影响结果。如果每次测法不同，分数变化就很难指导优化。
代码示例
一个性能基线通常同时记录实验室检查和真实用户指标。
Text
baseline:
page: /dashboard
device: mobile
network: simulated 4G
lighthouse runs: 5
budget:
LCP p75 <= 2500ms
INP p75 <= 200ms
CLS p75 <= 0.1
initial JS <= 180KB gzip常见误区
- 只看一次 Lighthouse 分数，不看波动、运行环境和真实用户数据。
- 只优化总分，不定位 LCP、INP、CLS 分别卡在哪里。
- 没有把基线接入发布对比，性能回退上线后才被发现。