以用户为中心的性能指标

Philip Walton

我们都听说过性能的重要性。但是，当我们谈论性能以及如何使网站“快速”时，具体指的是什么？

事实是性能是相对的

  • 对于一个用户（在快速网络和高性能设备上），网站可能很快，但对于另一个用户（在慢速网络和低端设备上），网站可能很慢。
  • 两个网站可能在完全相同的时间内完成加载，但其中一个网站看起来加载速度更快（如果它逐步加载内容，而不是等到最后才显示任何内容）。
  • 一个网站可能看起来加载很快，但随后对用户交互的响应却很慢（甚至没有响应）。

在谈论性能时，重要的是要精确，并以指标来指代性能。指标是可定量衡量的客观标准，但同样重要的是要确保您衡量的指标是有用的。

定义指标

从历史上看，Web 性能一直使用 load 事件来衡量。但是，即使 load 是页面生命周期中一个明确定义的时刻，但该时刻不一定与用户关心的任何事情相对应。

例如，服务器可能会响应一个最小化的页面，该页面会立即“加载”，但随后会延迟获取内容或在页面上显示任何内容，直到 load 事件触发后几秒钟。这样的页面在技术上具有快速的加载时间，但该时间与用户体验页面加载的方式不符。

在过去的几年中，Chrome 团队的成员与 W3C Web 性能工作组 合作，一直致力于标准化一组新的 API 和指标，以便更准确地衡量用户体验网页性能的方式。

为了帮助确保指标与用户相关，我们围绕以下几个关键问题来构建它们

是否正在发生？ 导航是否成功开始？服务器是否已响应？
是否有用？ 是否已呈现足够的内容，以便用户可以与之互动？
是否可用？ 用户可以与页面互动吗？还是页面正忙？
是否令人愉悦？ 交互是否流畅自然，没有延迟？

如何衡量指标

性能指标通常通过以下两种方式之一来衡量

  • 在实验室中：使用工具在一致的、受控的环境中模拟页面加载
  • 在现场：在真实用户实际加载页面并与之互动时进行衡量

这两种选择都并非一定优于或劣于另一种——事实上，您通常希望同时使用两者以确保良好的性能。

在实验室中

在开发新功能时，在实验室中测试性能至关重要。在功能发布到生产环境之前，无法衡量其在真实用户上的性能特征，因此在功能发布之前在实验室中对其进行测试是防止性能下降的最佳方法。

在现场

另一方面，虽然在实验室中进行测试是性能的合理代表，但它不一定能反映实际用户体验您网站的方式。

网站的性能可能会因用户的设备性能和网络状况而发生巨大变化。它也可能因用户与页面交互的方式（或交互程度）而异。

页面加载也并非总是确定性的。例如，加载个性化内容或广告的网站可能会在用户之间体验到截然不同的性能特征。实验室测试无法捕捉到这些差异。

真正了解您的网站对用户表现如何的唯一方法是实际衡量用户在加载页面并与之互动时的性能。这种类型的衡量通常称为 真实用户监控 (RUM)。

指标类型

还有几种其他类型的指标与用户感知性能的方式有关。

  • 感知加载速度：页面加载并将其所有视觉元素渲染到屏幕的速度。
  • 加载响应性：页面加载并执行任何必需的 JavaScript 代码以使组件能够快速响应用户交互的速度
  • 运行时响应性：页面加载后，页面响应用户交互的速度。
  • 视觉稳定性：页面上的元素是否以用户不期望的方式移动，并可能干扰他们的互动？
  • 流畅度：过渡和动画是否以一致的帧速率渲染，并从一个状态流畅地过渡到下一个状态？

考虑到所有这些类型的性能指标，希望很明显，没有哪个单一指标足以捕捉页面的所有性能特征。

需要衡量的重要指标

在某些情况下，将引入新的指标来弥补缺失的领域，但在其他情况下，最佳指标是专门为您的网站量身定制的指标。

自定义指标

前面介绍的性能指标非常适合大致了解 Web 上大多数网站的性能特征。它们也非常适合为网站提供一套通用指标，以便将其性能与其竞争对手进行比较。

但是，有时特定网站可能在某些方面是独一无二的，需要额外的指标来捕捉完整的性能图景。例如，LCP 指标旨在衡量页面主要内容何时完成加载，但在某些情况下，最大元素可能不是页面主要内容的一部分，因此 LCP 可能不相关。

为了解决此类情况，Web 性能工作组还标准化了较低级别的 API，这些 API 可用于实施您自己的自定义指标

请参阅关于自定义指标的指南，了解如何使用这些 API 来衡量特定于您网站的性能特征。