同一个 URL，A 份报告说它表现健康，B 份报告说它问题不小，两份都是真的——因为实验室数据来自一套固定的设备与网络条件，真实数据来自所有访客各自的设备、网络和操作方式。web.dev 专门写过一页解释这件事并给出处理办法，看懂它之后，你会少改很多本来不需要改的地方。
两种数据分别在量什么
实验室数据是把页面放进一个受控环境里加载一次：一台设备、一条网络、一个地理位置。它的好处是结果可复现，适合开发阶段验证某个改动有没有用。真实数据（field）则是所有访客各自的体验汇总，它不是一个数，而是一整条分布：有人打开很快，有人打开很慢。
两个工具在报告里通常给的是分布上的一个点。给核心网页指标打分的工具报的是第 75 百分位，也就是表现较好的那 75% 访客的水平。接下来的麻烦全来自这一点：实验室那一次加载，恰好落在分布的哪个位置，是没有保证的。
即使条件一样，实验室分数本身也会抖。Lighthouse 性能评分的官方文档把常见原因列了几条：正在跑 A/B 测试或广告投放发生变化、网络路由变化、测试所用设备不同、浏览器扩展注入了脚本、杀毒软件。另外要记住它自己的计分方式：总分只是几个指标值的加权平均，机会项与诊断项本身不计入总分，所以删掉一条建议不会让分数直接上涨。文档同时建议，把站点性能看成分布而不是一个数更有用。
同一页面的 LCP 元素都可能不是同一个
这是最容易被忽略的一条。实验室跑一次，每次报出来的 LCP 元素都是同一个；真实数据里，同一页会出现各种不同的 LCP 元素，因为下列每一样都会改变视口里最大的那块内容是什么：屏幕尺寸不同、访客是否已登录或看到个性化内容、页面是否正在跑 A/B 测试、访客系统里装了哪些字体、以及访客是不是从带片段标识的链接跳进来的（那样首屏可能在页面中部而不是顶部）。
连带后果是：如果超过四分之一的访客的 LCP 元素本来就很快（比如一段用系统字体渲染的文字），那一部分慢图根本不会拉低这一页的第 75 百分位。反过来也成立——实验室模拟的设备视口小，把首屏大图判成了"不在视口内"，而真实访客用的是大屏手机，那张图就是他的 LCP 元素。那篇讲实验室与真实数据差异的指南把这几类情况逐条列了出来。
INP 与 CLS 在实验室里的先天短板
INP 需要有人真的动手点。实验室里没有真实输入，工具测不出 INP，只能拿 TBT 作代理；而 TBT 只看加载期间主线程被堵了多久，既不知道用户什么时候会点，也不包含某些移动端特有的点击等待。所以 TBT 很漂亮而 INP 很差，是完全可能发生的。
CLS 的短板在另一头：实验室通常只做一次基本加载，因此只看得到加载期间、首屏之内的位移；真实数据统计的是整段访问里的意外位移，用户往下滚时才触发的懒加载位移算在里面。而这类问题恰恰只在首访、缓存为空时最明显——实验室正好是空缓存，实验室的分数因此还可能偏高。
排优先级要按这个顺序
- 先看真实数据。它代表访客真正的体验，是判断"要不要动手"的第一依据。
- 在真实数据里按 URL 分组圈出页面量最大、状态最差的几组，先解决这一层，不要从最差的那个单页开始。
- 再看实验室数据。它回答的是"我这一处改动有没有用"，不是"我站好不好"。
- 两边差距大到需要解释时，回到上面那几类成因逐条排除，而不是取一个折中值。
如果你还缺一份可信的前台现状清单，站内旧文WordPress 网站 SEO：主机、性能、内容与持续维护和SEO 与性能优化的 10 款工具可以当清单用，不必在这篇里重复。
什么时候数字差不是站点的问题
四种情况值得先放一放。一是工具本身覆盖的用户就不是全部：web.dev 讲公开数据集与自建监测差异的那一页指出，Google 那个公开数据集只收 Chrome 浏览器用户，iOS 上的 Chrome 用的并不是同一个内核、不计入其中；自建监测则常因同意弹窗或拦截工具而只覆盖部分访客。二是两边统计窗口不同：公开数据集用的是 28 天滑动窗口，改完配置要等窗口走完才看得到变化。三是流量结构变了：某个时期涌入大量新访客，首次访问与回访的表现本来就不一样。四是这个 URL 的样本量根本不够，任何统计结论都没有意义。
还有一条边界要说清：web.dev 的 Web Vitals 说明把阈值写成建议口径——LCP 2.5 秒、INP 200 毫秒、CLS 0.1，按第 75 百分位、移动与桌面分开。它没有、也不打算给出"分数提高多少就换来多少排名"的换算关系，把两类数据当体验诊断材料用，是这个指标的正确定位。
怎么复核
复核的动作是让两次报告可比：固定测试时段与设备档位，关掉会注入脚本的扩展，避开正在投放的广告与实验；比对时确认两端取的是同一类数据（都是真实数据，或都是实验室数据）、同一设备分组、同一时间窗口。做完这些再逐条列出两边的差值，把每一处差值挂到上面那几类成因上，而不是笼统归因为"环境不一样"。
