真实场景中的核心网页指标：找出用户真正感觉到的那个瓶颈
把实验室测试与真实用户的核心网页指标结合起来，排定修复优先级，并在移动端与桌面端验证改进效果。
一次很快的实验室跑分是线索，不是最终判决
一个页面可以在受控测试中显得很快，但落在老旧手机、繁忙网络或到服务器距离很远的访客手里依然很慢。实验室测试的价值在于复现一次页面加载并暴露请求瀑布图；真实用户数据则显示真实访问在各种设备和条件下的表现。两者都要用：真实用户数据负责挑出问题，可重复的实验室运行负责定位和修复。
Google 在第 75 百分位上评估三项核心网页指标，并且移动端与桌面端分开看待。当前的“良好”目标是 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。平均值会掩盖相当一部分访客的更慢体验，所以要盯百分位数据，并按设备拆分。Google 的阈值指南解释了百分位方法。
从没达标的那一项开始
LCP 指向加载。 先确认延迟来自 HTML 响应之前、来自阻塞渲染的 CSS，还是来自发现并下载主视觉图或主文本。跨地区对比 TTFB，然后检查请求瀑布图。压缩主视觉图并给它正确的尺寸，让它在初始 HTML 中就能被发现，并且只当它确实是 LCP 元素时才预加载。
INP 指向交互。 页面加载类的实验室测试无法完整测量 INP，因为它需要真实的用户交互。先用真实用户数据找出缓慢的交互，再在浏览器开发者工具里对相应的点击或按键做性能剖析。过长的 JavaScript 任务、昂贵的渲染，以及第三方脚本，都会推迟下一次绘制。把工作拆成更小的任务、把非必要脚本延后执行，是两个不错的首选实验。web.dev 的测量指南解释了为什么总阻塞时间只是实验室里的替代指标，不能取代 INP。
CLS 指向视觉位移。 在真实用户数据里同时检查首次加载和后续交互。为图片和嵌入内容设定明确的尺寸或宽高比，为广告预留空间，避免把内容插到用户正在阅读的材料上方。字体替换也会推动文字：使用度量值相近的回退字体，并在真实渲染的页面上验证。
把一个分数变成一次受控实验
一次只改一个可疑的原因。保持路由、视口、设备档位、缓存状态和测试地点一致，并且多跑几次。对比请求瀑布图和相关的那一项指标，而不只是一个总分。改动上线之后，再看真实用户数据：一条路由或一种设备上的改善，未必会迁移到每一个页面。
做真实用户数据监控时，把相似的页面模板归为一组，先查受影响最严重的设备分段。一个共用的页头或同意管理组件可能影响大量 URL，而某张商品图可能只影响一个模板。这种分组有助于区分全站问题和单页问题。
把用户体验排在完美数字前面
核心网页指标是有用的诊断工具，而不是“什么是一个好网站”的完整定义。Google 表示，核心网页指标报告中的良好结果并不保证搜索排名靠前，相关性和更广义的页面体验依然重要。去修复用户真实遇到的、可测量的摩擦点，用这些指标来验证改动，而不是孤立地追逐一个分数。Google 的页面体验指南提供了相关背景。