Core Web Vitals：Google Web 性能指标指南

谷歌希望人们拥有良好的网络体验，因此它在搜索结果中排名靠前的网站。当然，这是一种粗略的简化，但是，假设您正在比较具有相似内容和受众的两个站点，则速度越快的站点在结果中的表现应该越高。但谷歌如何衡量这一点一直有点像猜谜游戏，因此它引入了 Core Web Vitals 来为网站所有者和开发人员提供一些急需的清晰度。

不幸的是，“性能”是许多指标的统称……第一个字节的时间、开始渲染、CPU 使用率、JavaScript 堆大小、第一次内容绘制、第一次有意义的绘制、第一次 CPU 空闲、DOM 加载、页面完全加载、交互时间、每秒样式重新计算等等。

不同的工具返回不同的结果集，可能很难知道从哪里开始。

Google 的 Web Vitals 计划旨在简化性能评估并帮助您专注于最重要的改进。Core Web Vitals 是反映真实用户体验的关键性能指标。有些是由 Chrome DevTools、PageSpeed Insights和Google Search Console 中的 Lighthouse 面板报告的。

该网络的命脉JavaScript库，从真实用户访问你的网站可以帮助测量更真实的指标。结果可以发布到 Google Analytics 或其他端点以供进一步分析。

Google 建议使用第 75 个百分位数，即记录同一指标的多个结果，将它们按从最佳到最差的顺序进行排序，然后在四分之三点处分析数字。因此，四分之三的站点访问者将体验到这种级别的性能。

当前的 Core Web Vitals 是Largest Contentful Paint、First Input Delay和Cumulative Layout Shift，它们相应地评估加载、交互性和视觉稳定性。

最大的内容绘制 (LCP)

LCP 衡量加载性能——内容出现的速度。

页面加载等历史指标DOMContentLoaded在这方面一直很挣扎，因为它们并不总是代表用户体验。例如，启动画面几乎可以立即出现，但由进一步的 Ajax 请求加载的可用内容可能需要更长的时间才能出现。

最大内容绘制 (LCP) 报告视口内可见的最大图像或文本块的渲染时间。低于 2.5 秒的时间被认为是好的，而高于 4.0 秒的任何时间都被认为是差的。

LCP 中考虑的元素类型是：

• <img> 元素

• <image> 里面的元素 <svg>

• <video>元素的海报图像

• 带有使用 CSSurl()属性加载的背景图像的元素

• 包含文本节点的块级元素。

最大元素在内容加载时确定，大小计算为其在浏览器视口中的可见尺寸。

LCP 可能受以下因素影响：

• 服务器响应时间

• 资源加载时间

• 渲染阻塞 CSS 或 JavaScript

• 客户规模的处理时间

LCP 改进可能通过以下方式实现：

1. 使用内容交付网络 (CDN) 将请求路由到更近的服务器

2. 通过最小化昂贵的渲染时间进程的数量来优化服务器响应

3. 最小化资产的文件大小

4. 在本地缓存资产，也许首先使用服务工作者返回本地版本。

首次输入延迟 (FID)

FID 衡量响应能力——页面对用户操作的响应速度。

该指标记录从用户与页面交互（点击、点击、按键等）到浏览器开始处理该事件处理程序的时间。小于 100 毫秒的延迟被认为是好的，而超过 300 毫秒的任何延迟都被认为是差的。

只有当应用程序服务于真实用户时，才能准确测量 FID。此外，它只测量事件处理的延迟——而不是运行处理程序或更新 UI 所花费的时间。

因此，谷歌和各种工具使用总阻塞时间 (TBT) 作为替代指标，无需实际用户输入即可计算。TBT 测量以下之间的总时间：

1. 第一次内容绘制（FCP）——页面内容的任何部分被渲染的时间，以及

2. 交互时间 (TTI) — 页面能够可靠地响应用户输入的时间（没有长时间的任务正在运行，并且尚未解决的 GET 请求不超过两个）。

FID/TBT 改进可能通过以下方式实现：

1. 减少 JavaScript 执行时间，通常是通过推迟非关键代码

2. 分解长时间运行的任务

3. 使用Web Worker在后台线程中运行任务

4. 按需加载第三方 JavaScript。

累积布局偏移 (CLS)

CLS 测量视觉稳定性 -查看页面时内容的意外移动。

当内容在没有警告的情况下移动时，CLS 会评估那些烦人的情况——通常是在当前滚动位置上方的广告或图像完成加载后 DOM 发生变化时。该问题在移动设备上尤为明显，可能会导致您丢失位置或点击错误链接。

CLS 的计算方法是：

1. 影响分数：视口中不稳定元素（将移动的元素）的总面积。0.5 的影响分数表示占视口一半的元素将被置换。

2. 距离分数：视口内任何单个元素移动的最大距离。0.25 的距离分数表示至少有一个元素移动了视口的四分之一（水平或垂直）。

考虑以下示例，该示例在呈现徽标、菜单和英雄图像后不久加载广告：

标志和菜单不动——它们是稳定的元素。广告添加到 DOM 并且它的起始位置没有改变所以它也是稳定的。但是，英雄形象会移动：

1. 英雄在 360 x 720 视口中为 360 x 510 像素。因此它的影响分数是 (360 x 510) / (360 x 720) = 0.71

2. 它在 720px 视口高度内移动 90 个垂直像素，所以它的距离分数是 90 / 720 = 0.125

因此 CLS 为 0.71 x 0.125 = 0.089

CLS 分数低于 0.1 被认为是好的，任何高于 0.25 的都被认为是差的。在这种情况下，CLS 刚好在可接受的范围内，因为虽然受影响的区域很大，但移动的距离相对较小。不过，更大的广告需要进一步关注。

在任何可能触发 UI 更改或视口调整大小的用户交互之后，CLS 算法不会记录 500 毫秒的布局偏移。因此，您的页面不会因操作所需的界面更新、转换和动画而受到惩罚，例如从汉堡包图标打开全屏菜单。

Chrome DevTools 中的渲染面板（菜单 > 更多工具 > 渲染）提供了一个Layout Shift Regions选项。选中该框并刷新页面 - 布局偏移以蓝色突出显示。您还可以在“网络”面板中修改网络速度以减慢加载速度。

FID/TBT 改进可能通过以下方式实现：

1. 通过添加维度width和height属性、CSSaspect-ratio属性或适当的旧填充技巧，为图像、视频和 iframe 元素保留空间

2. 在加载网络字体时避免 FOUT（无样式文本的闪烁）和 FOIT（不可见文本的闪烁）。预加载或使用类似大小的后备字体将有所帮助

3. 在初始页面加载期间不要在现有内容上方插入 DOM 元素，例如时事通讯注册和类似的通知框

4. 使用 CSStransform和opacity成本较低的动画。

性能优先级

Core Web Vitals 会随着时间的推移而发展，但评估 LCP、FID 和 CLS 指标可以帮助确定最关键的问题。首先解决快速而简单的问题——它们通常具有最大的投资回报：

• 激活服务器压缩和 HTTP/2 或 HTTP/3

• 通过设置 HTTP 过期标头确保使用浏览器缓存

• 尽早预加载资产

• 连接和缩小 CSS 和 JavaScript

• 删除未使用的资产

• 考虑使用 CDN 或更好的托管

• 使用适当的图像大小和格式

• 优化图像和视频文件大小（专业 CDN 可以提供帮助）