Core Web Vitals 检测工具，定位网页性能短板
测速度最容易搞混的一件事：实验室数据和真实用户数据是两个东西，结论常常对不上。你在自己电脑上跑出来 95 分，页面在用户手机上可能卡得要命；反过来也一样。搞清楚这两类数据各自代表什么，是定位性能短板的前提。
三个指标的定义与达标线、以及逐项优化方式见Core Web Vitals 核心网页指标优化完整实操，本文只讲用什么工具测、怎么定位是哪一块拖后腿。
一、两类数据的区别
| 实验室数据 | 真实用户数据（实测数据） | |
|---|---|---|
| 怎么来的 | 模拟环境里加载一次 | 真实用户访问时采集，来自 Chrome 用户体验报告 |
| 代表什么 | "在特定条件下这次跑了多少分" | "真实用户实际体验如何" |
| 稳定性 | 同一页面多次跑分可能差很多 | 按一段时间滚动统计，稳定 |
| 门槛 | 任何页面都能跑 | 页面流量足够才有数据，小站很多页面没有 |
| 在哪看 | Lighthouse、PageSpeed Insights 的分析部分 | PageSpeed Insights 顶部、GSC 核心网页指标报告 |
| 用途 | 复现问题、验证改动当场有没有效 | 判断真实状况、决定要不要改 |
结论很直接：决定"要不要改"看实测数据，验证"改了有没有用"看实验室数据。只盯实验室分数，容易把力气花在真实用户根本没感觉的地方。
二、工具对照
| 工具 | 数据类 | 免费 | 最适合做什么 | 局限 |
|---|---|---|---|---|
| PageSpeed Insights | 两者都有 | 是 | 单页快速诊断，一个地址看到实验室 + 实测 | 一次只能测一个网址 |
| Lighthouse（Chrome 开发者工具内置） | 实验室 | 是 | 边改边测，看改动当场的反馈 | 受本机环境、插件、缓存影响大 |
| GSC 核心网页指标报告 | 实测 | 是 | 按问题类型分组看全站有多少页面不达标 | 只有流量足够的页面才有数据；更新有延迟 |
| WebPageTest | 实验室 | 有免费额度 | 指定地区、网络条件、设备来复现特定用户的体验 | 配置项多，新手容易看花眼 |
| Chrome 用户体验报告看板 | 实测 | 是 | 看整个行业或整站的历史趋势 | 粒度粗，定位不到具体页面问题 |
三、按指标定位短板
| 指标 | 测什么 | 达标线 | 常见拖后腿的原因 | 定位工具 |
|---|---|---|---|---|
| LCP | 最大内容的出现时间 | 2.5 秒以内 | 主图体积过大、服务器响应慢、渲染被脚本阻塞 | PSI 会直接指出最大内容元素是哪一个，照着改最有效 |
| INP | 交互到页面给出反馈的延迟 | 200 毫秒以内 | 脚本执行时间长、事件处理逻辑重 | Lighthouse 的诊断项能看出脚本占用；真实交互要人工复现 |
| CLS | 视觉元素意外位移的累计量 | 0.1 以内 | 图片和广告没预留尺寸、字体替换导致跳动、内容延迟插入 | Lighthouse 会列出具体发生位移的元素 |
三项目标按页面访问量的第 75 百分位判定——也就是说，看的是"大多数用户的体验"，不是平均值。少数极端慢的访问不会拉低判定，但如果你那 25% 恰好是核心客户，还是要单独看。
四、怎么判断该不该改
性能优化是有成本的，别看到分数低就动手。用这三个问题筛一遍：
- 这个页面有没有真实用户数据？没有实测数据的页面，通常流量很小，改了也影响不了几个人，优先级往后放；
- 不达标的是哪个指标？LCP 和 CLS 通常改起来见效快（压缩图片、预留尺寸）；INP 涉及脚本改造，成本高，先确认这个页面值不值得；
- 是模板问题还是单页问题？GSC 报告按问题类型把页面分组，如果一整组几十个页面是同一个原因，改一次模板就全好了——先改这类，投入产出比最高。
五、两个提醒
- 速度是页面体验信号之一，不是排名主因。内容对不上搜索意图，页面秒开也排不上去；
- 实验室分数波动是正常的。同一页面连跑三次差十几分很常见，判断改动效果要看多次结果，别拿单次分数当结论。
来源：https://web.dev/articles/vitals
来源：https://developers.google.com/search/docs/appearance/page-experience
来源：https://developer.chrome.com/docs/lighthouse/overview