收集网站的 Web Vitals 数据是改进这些指标的第一步。全面的分析会收集来自真实环境和实验室环境的性能数据。衡量 Web 指标只需极少的代码更改，并且可以使用免费工具完成。
使用 RUM 数据衡量网页指标
实时用户监控 (RUM) 数据（也称为“实测数据”）用于捕获网站实际用户所体验到的性能。Google 就使用 RUM 数据来确定某个网站是否符合建议的核心网页指标阈值。
使用入门
如果您未设置 RUM，以下工具可快速为您提供有关网站实际性能的数据。这些工具都基于同一底层数据集（即 Chrome 用户体验报告），但使用场景略有不同：
- Chrome 开发者工具与“性能”面板的实时指标视图中的 CrUX 数据集集成。通过将本地体验与同一网页上的实际用户体验进行比较，您可以更明智地决定将调试工作重点放在何处。如果您想采取一项措施来开始衡量和改进网站的 Web Vitals，我们建议您使用 Chrome 开发者工具的“性能”面板。
- PageSpeed Insights (PSI) 会报告过去 28 天内的网页级和来源级汇总效果。此外，它还会提供有关如何提升效果的建议。PSI 可在网页上使用，也可作为 API 使用。
- Search Console 会按网页报告效果数据。因此，它非常适合用于确定需要改进的特定网页。与 PageSpeed Insights 不同，Search Console 报告包含历史效果数据。Search Console 只能用于您拥有且已验证所有权的网站。
- CrUX Vis 是一个预建的信息中心，可显示您选择的网址或来源（如果 CrUX 数据集中有相应数据）的 CrUX 历史数据。它基于 CrUX History API 构建，设置过程大约需要一分钟。与 PageSpeed Insights 和 Search Console 相比，CrUX Vis 包含更多数据示例、LCP 子部分、导航类型等。
- CrUX Vis 是一个历史记录信息中心，可显示您选择的来源或网址的 CrUX 数据。它基于 CrUX History API 构建。与 PageSpeed Insights 和 Search Console 相比，CrUX Vis 报告包含更多详细信息，例如，CrUX Vis 中提供了导航类型以及 LCP 和 RTT 数据。
值得注意的是，虽然前面列出的工具非常适合“开始”衡量 Web 指标，但它们在其他情况下也很有用。特别是，CrUX 和 PSI 均以 API 形式提供，可用于构建信息中心和其他报告。
收集 RUM 数据
虽然基于 CrUX 的工具是调查网页指标性能的良好起点，但我们强烈建议您使用自己的 RUM 对其进行补充。您自行收集的 RUM 数据可以提供有关网站性能的更详细、更即时的反馈。这样一来，您就可以更轻松地发现问题并测试可能的解决方案。
您可以使用专门的 RUM 提供商或设置自己的工具来收集自己的 RUM 数据。
专用 RUM 提供商专门负责收集和报告 RUM 数据。如需将核心网页指标与这些服务搭配使用，请咨询您的 RUM 提供商，了解如何为您的网站启用核心网页指标监控功能。
如果您没有 RUM 提供商，或许可以使用 web-vitals JavaScript 库来扩充现有的分析设置，以收集和报告这些指标。接下来将更详细地介绍此方法。
web-vitals JavaScript 库
如果您要自行实现 Web 指标的 RUM 设置，收集 Web 指标衡量数据的最简单方法是使用 web-vitals JavaScript 库。web-vitals 是一个小型模块化库（约 2 KB），可提供便捷的 API 来收集和报告每个可现场测量的 Web Vitals 指标。
构成网页指标的各项指标并非全部由浏览器的内置性能 API 直接公开，而是基于这些 API 构建的。例如，Cumulative Layout Shift (CLS) 是使用 Layout Instability API 实现的。使用 web-vitals，您无需自行实现这些指标，还可以确保您收集的数据符合每项指标的方法和最佳实践。
如需详细了解如何实现 web-vitals，请参阅文档和衡量实际网页指标的最佳实践指南。
数据汇总
请务必报告 web-vitals 收集的衡量数据。如果系统测量了这些数据，但未报告，您将永远无法看到。web-vitals 文档中包含一些示例，展示了如何将数据发送到通用 API 端点、Google Analytics 或 Google 跟踪代码管理器。
如果您已有喜爱的报告工具，不妨考虑使用该工具。如果不是，Google Analytics 是免费的，可用于此目的。
在考虑使用哪种工具时，不妨先想想哪些人需要访问数据。通常情况下，如果整个公司（而非单个部门）都对提升效果感兴趣，企业就能取得最大的效果提升。如需了解如何获得不同部门的支持，请参阅跨职能部门提升网站速度。
数据解读
分析效果数据时，请务必注意分布的尾部。RUM 数据通常会显示性能差异很大，有些用户体验到的是快速的性能，而有些用户体验到的是缓慢的性能。不过，使用中位数汇总数据可能会掩盖这种行为。
对于 Web Vitals，Google 使用“良好”体验的百分比，而不是中位数或平均值等统计信息，来确定网站或网页是否符合建议的阈值。具体而言，如果网站或网页要被视为达到核心网页指标阈值，则 75% 的网页访问应达到每项指标的“良好”阈值。
使用实验数据衡量网页指标
实验室数据（也称为合成数据）是从受控环境中收集的，而不是从实际用户那里收集的。与 RUM 数据不同，实验室数据可以从预生产环境中收集，因此可以纳入开发者工作流程和持续集成流程。收集合成数据的工具示例包括 Lighthouse 和 WebPageTest。
注意事项
RUM 数据与实验室数据之间始终存在差异，尤其是在实验室环境的网络条件、设备类型或位置与用户的网络条件、设备类型或位置存在显著差异时。不过，在收集有关核心网页指标的实验数据时，有几点需要特别注意：
- 由于网页加载延迟（通过重定向、连接到服务器的延迟或未缓存的数据）、根据屏幕向不同用户显示的不同内容，或其他原因（包括 Cookie 横幅、个性化），在实验室环境中测得的 Largest Contentful Paint (LCP) 可能与使用 RUM 数据在实际环境中测得的 LCP 不同。
- 在实验环境中测得的累积布局偏移 (CLS) 可能人为地低于在 RUM 数据中观测到的 CLS。许多实验室工具只会加载网页，而不会与之互动。因此，它们仅捕获在初始网页加载期间发生的布局偏移。相比之下，RUM 工具测量的 CLS 会捕获在网页的整个生命周期内发生的意外布局偏移。
- Interaction to Next Paint (INP) 无法在实验环境中进行衡量，因为该指标需要用户与网页互动。因此，建议使用 Total Blocking Time (TBT) 作为 INP 的实验室代理指标。TBT 衡量的是“从首次内容渲染到可交互时间之间的总时长，在此期间，网页无法响应用户输入”。虽然 INP 和 TBT 的计算方式不同，但它们都反映了在启动过程中主线程被阻塞的情况。当主线程被阻塞时，浏览器会延迟响应用户互动。
工具
这些工具可用于收集 Web 指标的实验性测量结果：
- Chrome DevTools 会在“性能”面板的实时指标视图中衡量并报告指定网页的核心网页指标。此视图可在开发者更改代码时提供实时性能反馈。
- Lighthouse Lighthouse 会报告 LCP、CLS 和 TBT，还会突出显示可能的性能改进。Lighthouse 可在 Chrome 开发者工具中作为 npm 软件包使用，也可使用 Lighthouse CI 集成到持续集成工作流中。
- WebPageTest 将 Web 指标纳入其标准报告中。WebPageTest 可用于在特定设备和网络条件下收集有关 Web 指标的信息。