网站 Web Vitals 数据收集：全面分析与工具指南

收集网站的 Web Vitals 数据是改善网站性能的第一步。全面的分析需要同时从实际环境和实验室环境收集性能数据。测量 Web Vitals 时应尽量减少代码改动，可以利用免费工具进行数据收集。

使用 RUM 数据测量 Web 指标

真实用户监控（RUM）数据，也称为现场数据，能够反映网站真实用户所体验到的性能表现。Google 使用 RUM 数据来判断网站是否满足推荐的 Core Web Vitals 基准值。

入门指南

如果尚未设置 RUM，可以使用以下工具快速获取网站的实际性能数据。这些工具都基于相同的基础数据集（Chrome 用户体验报告），但使用场景略有不同。

Chrome DevTools 在其性能面板的实时指标视图中集成了 CrUX 数据集。通过将本地体验与同一页面的真实用户体验进行比较，可以更准确地确定需要重点调试的部分。如果您希望快速开始测量和改善网站的 Web Vitals，推荐使用 Chrome DevTools 的性能面板。

PageSpeed Insights（PSI） 报告过去 28 天的页面级和源级性能汇总，并提供改善性能的建议。PSI 可通过网页和 API 使用。

Search Console 提供页面级别的性能数据报告，适合识别需要改进的特定页面。与 PageSpeed Insights 不同，Search Console 的报告包含历史性能数据。请注意，Search Console 仅适用于已验证所有权的网站。

CrUX Vis 是一个预构建的仪表板，显示所选 URL 或源（若 CrUX 数据集中可用）的 CrUX 历史数据。它基于 CrUX History API 构建，设置过程仅需一分钟左右。与 PageSpeed Insights 和 Search Console 相比，CrUX Vis 包含更多数据，例如 LCP 子部分和导航类型。

CrUX Vis 是展示选定源或 URL 的 CrUX 数据的仪表板。它构建在 CrUX History API 之上。与 PageSpeed Insights 和 Search Console 相比，CrUX Vis 报告包含更详细的信息，例如导航类型以及 LCP 和 RTT 数据。

需要注意的是，虽然上述工具适合“入门”测量 Web Vitals，但它们在其他场景中同样有用。特别是 CrUX 和 PSI 都提供 API，可用于构建仪表板和其他报告。

收集 RUM 数据

基于 CrUX 的工具是调查 Web Vitals 性能的良好起点，但我们强烈建议补充使用自定义的 RUM 方案。通过自行收集 RUM 数据，可以获得更详细、更及时的网站性能反馈，从而更容易识别问题并测试可能的解决方案。

注意： 基于 CrUX 的数据源通常以约一个月为粒度报告数据，但具体细节因工具而异。例如，PSI 和 Search Console 报告过去 28 天的性能，而 CrUX 数据集和仪表板则按日历月分类。

您可以通过专用的 RUM 提供商或设置自己的工具来收集 RUM 数据。

专用 RUM 提供商 专注于 RUM 数据的收集和报告。若要在这些服务中使用 Core Web Vitals，请咨询您的 RUM 提供商如何启用网站上的 Core Web Vitals 监控。

如果没有 RUM 提供商，可以使用 web-vitals JavaScript 库扩展现有的分析设置，以收集和报告这些指标。下一节将详细介绍这种方法。

web-vitals JavaScript 库

如果要实现 Core Web Vitals 的自定义 RUM 设置，最简单的方法是使用 web-vitals JavaScript 库。web-vitals 是一个轻量级模块化库（约 2 KB），提供方便的 API 来收集和报告各项可在现场测量的 Web Vitals 指标。

Core Web Vitals 的组成指标并非直接由浏览器内置的性能 API 公开，而是构建在这些 API 之上。例如，Cumulative Layout Shift（CLS）使用 Layout Instability API 实现。使用 web-vitals 可以避免自行实现这些指标，并确保收集的数据符合各指标的方法论和最佳实践。

有关 web-vitals 实施的详细信息，请参阅其文档以及现场测量 Web Vitals 的最佳实践指南。

数据聚合

必须报告通过 web-vitals 收集的测量值。如果数据被测量但未报告，则无法被查看。web-vitals 文档中包含了如何将数据发送到通用 API 端点、Google Analytics 和 Google Tag Manager 的示例。

如果已有熟悉的报告工具，建议使用该工具。否则，可以免费使用 Google Analytics 来实现此目的。

在选择工具时，应考虑需要访问数据的人员。通常，当整个公司（而非单一部门）都关注性能改进时，企业才能实现最大的性能提升。关于如何获得跨部门支持的方法，请参阅跨部门改善网站速度的相关指南。

数据解读

在分析性能数据时，关注分布的尾部非常重要。RUM 数据经常显示性能存在显著差异：部分用户体验快速加载，而其他用户则可能经历较慢的加载速度。然而，如果使用中位数等统计量汇总数据，这种行为可能会被掩盖。

对于 Core Web Vitals，Google 使用“良好”体验的比例（而非中位数或平均值等统计信息）来判断站点或页面是否达到推荐阈值。具体而言，站点或页面要被认定为满足 Core Web Vitals 阈值，需要其 75% 的页面访问在每个指标上都达到“良好”标准。

使用实验室数据测量 Web 指标

实验室数据（也称为合成数据）是从受控环境而非真实用户收集的。与 RUM 数据不同，实验室数据可以从预生产环境收集，因此可以集成到开发者工作流和持续集成流程中。收集合成数据的工具示例包括 Lighthouse 和 WebPageTest。

注意事项

RUM 数据与实验室数据之间始终存在差异，尤其是在实验室的网络条件、设备类型和位置与用户环境显著不同的情况下。在收集 Web Vitals 指标的实验室数据时，有几个特别需要注意的要点：

• Largest Contentful Paint (LCP)：由于页面加载延迟（如重定向、服务器连接延迟、未缓存数据等）、屏幕上向用户显示内容的差异以及其他原因（如 Cookie 横幅、个性化设置等），实验室环境下的测量值可能与 RUM 数据存在差异。
• Cumulative Layout Shift (CLS)：实验室环境下测得的 CLS 可能人为地低于 RUM 数据观测值。许多实验室工具仅加载页面而不进行交互，因此仅捕获页面初始加载期间发生的布局偏移。而 RUM 工具测量的 CLS 则捕获整个页面生命周期中发生的意外布局偏移。
• Interaction to Next Paint (INP)：由于需要用户与页面交互，INP 无法在实验室环境中测量。因此，Total Blocking Time (TBT) 被推荐作为 INP 的实验室代理指标。TBT 测量“从 First Contentful Paint 到可交互时间之间，页面因长时间阻塞而无法响应用户输入的总时间”。尽管 INP 和 TBT 的计算方法不同，但它们都反映了引导过程中主线程被阻塞的情况。主线程阻塞会导致浏览器响应用户操作时出现延迟。

工具

可以使用以下工具收集 Web Vitals 的实验室测量值：

• Chrome DevTools：在性能面板的实时指标视图中，测量并报告特定页面的 Core Web Vitals。此视图在您进行代码更改时提供实时性能反馈。
• Lighthouse：生成关于 LCP、CLS 和 TBT 的报告，并突出显示可能改善性能的方面。Lighthouse 可在 Chrome DevTools 中使用，也可作为 npm 包提供。此外，还可以使用 Lighthouse CI 将其集成到持续集成工作流中。
• WebPageTest：在其标准报告中包含 Web Vitals。WebPageTest 有助于在特定设备和网络条件下收集 Web Vitals 信息。