Core Web Vitals：
加载、
响应、 稳定性
读懂加载、响应和布局偏移指标，定位问题原因，并核验开发人员的修复成果。
找出原因。
核验修复。
从简明定义到检查自己的网站：解析真实用户数据、实验室报告，以及红色指标背后的具体情况。
什么是 Core Web Vitals，为什么要检查
Core Web Vitals 包含三项页面体验指标：LCP 描述首屏中较大内容的出现时间，INP 衡量交互响应，CLS 衡量布局稳定性。结合使用，可以区分“看不到服务介绍”“按钮卡住了”“链接从手指下面移开了”等不同问题。
设想一个设备目录：标题和照片很快出现，但选择功率时，筛选器卡住了一秒。加载看起来不错，交互却有问题。另一个目录的筛选器即时响应，但广告条出现后，商品整体向下移动。单凭“网站很快”这一评价，无法描述这些不同情况。
在网站上线、更换模板、添加组件及定期技术审计时进行检查。优先检查访客了解服务并作出决定的页面：服务页、分类页、商品页和文章页。保存每种模板的代表性 URL，不能将首页的结果直接推广到整个网站。
帮助读懂指标，并提出可以验收的任务。有关测速服务、网络请求和 Yandex 报告的详细检查步骤，请参阅《如何检查网站加载速度》。
LCP、INP 和 CLS 的良好值
| 指标 | 良好 | 需要改进 | 较差 |
|---|---|---|---|
| LCP — 较大内容的出现 | ≤ 2.5 秒 | > 2.5 且 ≤ 4 秒 | > 4 秒 |
| INP — 交互延迟 | ≤ 200 毫秒 | > 200 且 ≤ 500 毫秒 | > 500 毫秒 |
| CLS — 布局偏移 | ≤ 0.1 | > 0.1 且 ≤ 0.25 | > 0.25 |
阈值依据以下指标的官方文档：LCP,INP以及CLS。CLS 是无量纲分数，写成“0.1 秒”是错误的。三项指标的值越低，对应的体验越好。
第 75 百分位数是什么意思
现场数据以 p75 评估，并分别统计移动设备和桌面设备。若 LCP 的 p75 为 2.3 秒，则至少 75% 的记录加载达到该值或更好。这不是算术平均值，也不意味着每位访客都能获得同样结果。
教学示例：一组移动页面的 LCP 为 2.2 秒，INP 为 310 毫秒，CLS 为 0.06。不能将整组评价为良好，因为响应仍需改进。数据充足时，PageSpeed 要求三项指标的 p75 均为良好才判定通过。如果 INP 数据不足，可以依据 LCP 和 CLS 评估；但这两项中任一缺失，就无法作出评估。有关说明见PageSpeed Insights 方法说明。
现场数据、实验室测试与 PageSpeed 分数
CrUX 现场数据反映参与数据采集的 Chrome 用户访问体验。PageSpeed 使用最近 28 天的滚动数据。Lighthouse 实验室报告则在指定限制条件下模拟一次加载，适合诊断问题，但无法复现受众的所有设备、页面和操作。
检查数据来源标签：统计可能针对某个 URL，也可能针对源站 origin，即协议、主机名与端口的组合。不能把 origin 数据当作当前文章单独的测量结果。“无数据”表示合适样本不足，不代表没有问题，也不代表速度为零。
| 报告 | 用途 | 需要记录什么 |
|---|---|---|
| PageSpeed 中的 CrUX | 了解访客积累的实际体验 | 设备、时间范围、URL 或 origin、p75 |
| Search Console 的 Core Web Vitals | 找出存在问题的同类页面组 | 页面组、指标、示例 URL、状态 |
| Lighthouse | 检查单次加载及其诊断提示 | URL、日期、模式、版本及报告链接 |
| Chrome Performance 面板 | 复现卡顿或布局偏移 | 操作顺序与性能录制 |
性能分数 100 不等于通过 Core Web Vitals。加载测试可能很快结束，但复杂筛选器只有点击后才运行。Lighthouse 还显示加载期间的总阻塞时间 TBT；它有助于定位问题，却不能代替真实交互的 INP。数据来源与统计时间范围应始终和数值一并呈现。
在哪里查看网站指标
PageSpeed Insights：从具体页面开始
- 打开PageSpeed Insights，输入完整的公开 URL，并开始分析。
- 选择移动设备视图。在真实用户性能区域，检查数据来源及每项指标，而不只看总评状态。
- 打开下方的实验室报告，找到 LCP、CLS 及与所见问题相关的诊断信息，并保存结果链接。
- 切换到桌面设备，并单独记录指标。这是另一种测试模式，并不能证明移动端结果。
- 对其他重要模板重复检查。若服务报错，应记录为测量未完成。
Search Console：从单页转向页面组
- 打开Google Search Console，并选择已验证的网站资源。
- 进入“Core Web Vitals”报告，然后打开移动设备或桌面设备报告。
- 选择问题，例如需要改进的 LCP。打开对应页面组的行，记录示例 URL。
- 检查这些页面的共同点：模板、大图、页头或广告区块。向开发人员提供几个典型示例。
- 修复页面组后，启动修复验证，并继续观察后续变化。
Search Console 会将体验相近的页面分组，因此页面组结果可能与 PageSpeed 中某个 URL 的结果不同。该报告并非网站全部地址的清单。分组和验证规则详见Google 帮助文档。
对于尚无现场数据的新网站，先保存实验室基线，并手动检查使用场景。修复明显跳动的按钮不必等待数据积累。但在验收记录中，不能用实验室数值冒充仍未知的现场指标。
主要内容出现过晚
LCP 记录视口中最大且符合条件的元素完成绘制的时间，例如图片或文本块。它不代表页面的所有文件都已加载。大横幅在手机上不一定是 LCP 元素，因为布局调整后，标题可能成为最大的元素。
先在报告中确认具体元素，再分别分析首个服务器响应的等待时间、资源请求开始前的延迟、资源加载时间及显示延迟。如果文件已经下载，但元素要等动画结束才显示，进一步压缩图片也无法消除这段等待。
- 请求开始过晚。 检查图片能否在初始 HTML 中被发现，以及脚本是否延迟了它的出现。首屏主图通常不应与页面下方的图片一起使用懒加载。
- 文件传输耗时过长。 根据实际显示尺寸选择图片大小，检查响应式版本与压缩设置。替换后，应在手机和大屏显示器上查看细节。
- 服务器响应过晚。 检查请求处理与缓存。不要仅凭页面体积，就认定需要更换主机服务商。
- 内容在等待绘制。 检查阻塞渲染的样式、脚本执行、字体加载及入场效果。
这些是诊断方向，而不是每个网站都必须照做的改动清单。各阶段的拆解及缩短延迟的方法，可参阅web.dev 的 LCP 指南。
某移动服务页的最大元素是一张图片，但轮播脚本执行后才开始请求它。检查如何让浏览器更早发现图片，保留现有构图，并在原始条件下重新测量。附上该元素的截图，以及修改前后的时间线。
页面对操作响应缓慢
INP 统计整个访问期间的点击、触摸和按键交互，衡量交互发生后到下一帧显示的延迟，而不是整项远程操作的完成时间。它取代了仅衡量首次输入开始处理前延迟的 FID。单纯滚动页面并不属于 INP 测量的交互。
检查移动菜单、搜索、筛选、标签切换、问答展开和表单输入，并分别在加载中和加载后测试。编辑器空白页面的即时响应，不能证明拥有数百个条目且运行多个组件的目录页面表现正常。
如何复现响应缓慢
- 在 Chrome 中打开有问题的 URL，然后打开开发者工具和 Performance 面板。
- 开始录制，并执行一个具体场景，例如打开筛选器并选择一个值。
- 停止录制，找到延迟的交互以及当时运行的任务。
- 记录时间花在了哪里：处理函数运行前、函数执行中，还是准备下一帧时。
- 修复后，在相同限制条件下重复相同操作，并额外在真实目标设备上检查。
录制流程详见Performance 面板文档。如果问题来自大量计算，开发人员可以拆分任务；如果来自大范围重绘，可以缩小界面更新范围。应依据录制结果作出有证据的选择，具体方法见INP 优化指南。
教学场景：用户选择城市后，服务器计算配送方案。界面应立即反馈操作已接收，随后正确显示结果或错误。快速反馈有用，但不能成为无限等待的理由，也不能代替配送功能本身的测试。不要为某一个指标删除必要功能。
阅读时元素发生移动
CLS 衡量可见元素的意外布局偏移。当前计算取偏移分数最大的连续区间：相邻偏移间隔小于一秒，整个区间最长五秒。它不是整次访问中所有移动的简单总和。检查应覆盖加载过程以及后续使用。
常见检查位置包括未预留空间的图片、嵌入式视频、广告、延迟出现的通知，以及字体替换。服务页标题最初可能占两行，品牌字体加载后变成三行，导致下方内容移动。需要定位造成几何尺寸变化的具体原因。
- 为图片设置正确尺寸或宽高比，让文件加载前就预留好空间。
- 为动态区块约定预留空间，以及无数据时的显示行为。
- 检查备用字体和主字体的换行、按钮尺寸及标题高度。
- 重复阅读、滚动和展开内容。加载后的布局偏移，可能不会出现在短暂的首屏测试中。
并非每一次布局变化都算意外偏移。例如，用户完成一次离散操作后不久发生的偏移可能被排除。不过，按钮行为仍应可预测。计算方法详见CLS 定义文档；常见修复方法见优化指南。
商品页的分期付款区块延迟出现，并推移了购买按钮。修复后，应检查不同标题长度与价格的商品页、慢速网络，以及分期付款服务不响应的情况。所有情况下，按钮都必须保持可用。
为什么昂贵的设计不能保证良好指标
设计预算和视觉表现力，并不能说明页面的实现方式。同样的构图，可以使用合适图片和轻量过渡，也可能加载大型视频与多个动画库，并在它们启动前隐藏服务介绍。应评估实际上线的版本。
请团队在普通手机上展示首屏：效果加载前、加载后及交互过程中分别查看。明确每个重型元素的用途。有时调整加载顺序，或保留静态首帧，就能维持视觉创意；有时则需要重新设计妨碍阅读服务介绍的效果。应在测量后决定。
Google 在排名系统中使用 Core Web Vitals，但良好指标不保证排名靠前。提速无法修正内容不相关、索引被阻止或服务介绍不清晰等问题。以下官方说明明确指出这一点：Google 页面体验指南。
如果流量没有增长，应将搜索可见性和查询匹配度与技术速度分别检查。如果咨询没有送达，就复现用户路径。“把 CWV 做到绿色就能排名第一”不是可验收的技术成果。可以通过以下工作将这些问题联系起来：网站 SEO 审计。
如何排序优先级并向开发人员交付任务
先确认问题，再评估影响范围和使用场景的重要性。通用移动菜单的延迟会影响很多页面，而一篇少有人访问的文章中的大图，影响范围不同。不要给自动报告里的所有建议分配相同优先级。
在任务中注明初始结果和测试条件，不要只写“优化到绿色”。合适的表述是：“移动分类页选择品牌后，界面长时间没有可见反馈，已附 Performance 录制及操作步骤。请定位延迟来源、修复，并用同一场景验证结果。同时检查筛选状态保留、商品计数和商品详情跳转。”
在请开发人员介入前，负责人可以收集 URL、报告和录像，标注必要组件，找出媒体库中过大的原图，并检查图片字段。修改脚本、缓存及通用模板时，应准备备份并测试功能。批量删除分析工具或隐藏内容，不是改善体验的正确方式。
如需实际实施，网站技术维护与迭代可包含诊断、改动和效果核验。工作范围取决于问题原因，而不是报告中红色条目的数量。
如何验收修复并维持效果
发布后立即检查新版本，并重复实验室场景。旧现场数据不会瞬间消失，因为统计时间段仍包含修复前的访问。记录发布日期，之后与 CrUX 和 Search Console 的走势对照。
一次成功测试不保证效果稳定。应在可比条件下重复测量，保留结果波动，不要只挑最好的一份报告。为后续版本维护固定的检查页面集，因为新广告或组件可能让延迟再次出现。项目交付前的完整检查清单，请参阅网站开发交付验收指南。
关于 Core Web Vitals 还需要了解什么
Core Web Vitals 目前包含哪些指标？
LCP、INP 和 CLS。FID 是 INP 的前身。如果承包商只提供包含 FID 的旧报告，应要求重新检查当前的交互响应。
为什么 PageSpeed 显示 100 分，CWV 却未通过？
分数对应一次实验室加载，CWV 状态对应积累的现场数据。应核对时间段、设备、URL 或 origin 范围以及各项指标，不要把它们当成同一测试的两个结果。
仅重新加载页面就能检查 INP 吗？
有效检查响应必须执行点击、触摸或按键等操作。加载快和 TBT 低，并不能证明筛选器及菜单响应没有延迟。
网站没有 CrUX 数据怎么办？
记录数据缺失，检查实验室加载，并在目标设备上测试真实场景。待符合条件的数据足够时，再补充现场评估。不要编造缺失数值。
是否必须放弃动画和品牌字体？
不必自动删除。先确认延迟或偏移的真正原因，再选择能够保留可读性、视觉目的及界面功能的改动，并验证结果。
修复后指标什么时候更新？
实验室测试评估一次新的运行。现场报告反映积累的时间段，因此会逐步变化，且取决于数据是否充足。无法预先保证某个良好状态具体何时出现。