以用户为中心的效果指标

我们都听说过性能非常重要。但是,当我们谈论性能以及提高网站“快速”的速度时,具体指的是什么呢?

事实上,性能是相对的:

  • 对一位用户来说,网站可能加载速度很快(使用高速网络的网络连接),而其他用户访问网站的速度可能较慢(使用低端设备的慢速网络)。
  • 两个网站的完成时间可能完全相同,但其中一个网站的加载速度可能更快(如果网站是逐步加载内容,而不是等到最后才显示任何内容)。
  • 网站可能加载速度很快,但对用户互动的响应速度较慢(或根本不响应)。

因此,在讨论性能时,必须保持精确性,并按照可通过量化衡量的客观标准来指代性能。这些条件称为“指标”。metrics

但是,仅仅因为指标基于客观标准并且可以进行定量衡量,并不一定意味着这些衡量结果有用。

定义指标

过去,网站性能一直通过 load 事件来衡量。不过,虽然 load 是页面生命周期中一个明确定义的时刻,但该时刻不一定与用户关心的任何内容相对应。

例如,服务器可以使用一个立即“加载”的最小页面进行响应,但之后会延迟提取内容并显示该页面上的任何内容,直到 load 事件触发几秒后才显示。虽然从技术层面来讲,此类网页的加载时间可能较快,但该时间与用户实际获得的网页加载体验不符。

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

为确保指标与用户相关,我们在设计这些指标时要围绕几个关键问题:

是否发生这种问题? 导航是否成功启动?服务器是否有响应?
此功能是否有用? 是否呈现了足够多可供用户与之互动的内容?
是否可用? 用户能否与网页互动,或者该网页是否处于忙碌状态?
是否令人愉悦? 互动是否顺畅、自然,没有延迟和卡顿?

如何衡量指标

通常,我们会通过以下两种方式之一来衡量效果指标:

  • 在实验室中:使用工具在一致且受控的环境中模拟网页加载
  • 实际应用:针对实际用户加载网页并与之互动的情况

这两个选项并不一定优劣,实际上您一般希望同时使用这两者以确保获得良好性能。

实验室

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

实际应用

另一方面,虽然在实验室中进行测试是性能的合理代理,但并不一定能反映所有用户实际使用您网站时的体验。

网站的性能可能会因用户的设备功能和网络状况而发生显著变化。它还可能会根据用户是否(或如何与页面互动)而有所不同。

此外,网页加载次数可能并不确定。例如,加载个性化内容或广告的网站可能会因用户而异。实验室测试无法捕捉这些差异。

要想真正了解网站给用户带来的效果,唯一的方法就是实际衡量网站在用户加载网页并与之互动时的性能。这种类型的衡量通常称为实际用户监控(简称 RUM)。

指标类型

还有一些其他类型的指标与用户感受到的性能相关。

  • 感知加载速度:网页可以多快地加载网页中的所有视觉元素并将其渲染到屏幕上。
  • 加载响应速度:网页为了实现快速响应用户互动而加载和执行任何所需 JavaScript 代码的速度
  • 运行时响应速度:网页加载后,网页对用户互动的响应速度。
  • 视觉稳定性:页面上的元素是否会以用户意想不到且可能会干扰用户互动的方式发生变化?
  • 流畅性:过渡和动画是否以一致的帧速率渲染,并在一种状态之间流畅地流动?

鉴于上述所有类型的性能指标,很明显,没有哪一种指标足以捕获网页的所有性能特征。

要衡量的重要指标

虽然此列表包含用于衡量与用户相关的性能的很多方方面面的指标,但并未涵盖所有方面。例如,运行时响应和流畅性目前不涵盖在内。

在某些情况下,我们会引入新指标来涵盖缺失的方面,但在其他情况下,最佳指标是专门针对您的网站量身定制的指标。

自定义指标

上面列出的性能指标有助于大致了解网络上大多数网站的性能特征。它们还非常适合为网站提供一组通用指标,以便将其与竞争对手的效果进行比较。

不过,有时特定网站可能在某种程度上是与众不同的,需要额外的指标才能全面反映性能。例如,LCP 指标旨在衡量网页主要内容何时完成加载,但可能会出现以下情况:最大的元素不属于网页的主要内容,因此 LCP 可能不相关。

为了解决此类情况,网络性能工作组还对较低级别的 API 进行了标准化,对实现您自己的自定义指标很有用:

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