以用户为中心的性能指标

我们都听说过性能如何重要如何重要，但当我们讨论性能——可能就是让网站“快”，那么具体是什么意思呢？ 事实上，性能是一个相对的概念：

• 一个网站可能对某一个用户来说很快(在一个功能强大并且网络优质的设备上的时候)，但是对另一个用户来说就很慢(在一个网速很慢的低端设备上的时候)。
• 两个网站同时加载完成可能总耗时相同，但是有一个可能会加载地更快(如果这个网站渐进式加载而不是等到最后才展示页面)
• 一个网站可能看起来加载的很快，但是对用户交互却响应的很慢(甚至不响应)

所以当谈到性能，精确化和可以使用量化的客观标准计算是非常重要的。这些标准我们称之为指标。

但是仅仅因为指标是基于客观标准并且可以被量化，那也并不意味着这些计算是有用的。

指标定义

传统上，web 性能是通过加载事件来计算的。但是，即使加载事件是一个页面生命周期中定义的一个精准的时刻，这个时刻也并不与用户关心的任何东西相对应。

比如，一个服务器可能发送了一个最小化的页面立刻就加载了，但是推迟拉取内容和展示内容，直到数秒后负载事件发起。虽然这个页面可能加载的很快，但是这个很快并不对应一个用户感觉这个页面很快。

过去数年里，Chrome 团队成员和W3C Web Performance Working Group一直齐心努力标准化一些可以更精确计算用户如何感知网页性能的 API 和指标。

为了确保这些指标是用户相关的，我们围绕一些关键性问题展开：

关键性问题	举例
是否发生	导航成功启动了吗？服务器响应了吗？
是否有用	是否内容都渲染完毕了？
是否可用	用户可可以与页面交互了吗，还是页面很忙？
是否优雅	交互是否顺畅自然，没有滞后和停顿？

指标如何计算

性能指标一般有以下两种方式可以计算：

• 实验环境：使用工具模拟页面在一个相同的受控环境下加载
• 真实环境：通过实际加载页面和与之交互的用户计算

这些方法并没有一个确定的孰优孰劣的关系。实际上，你通常会同时使用两种方法以确保更好的性能

开发环境

当开发新功能的时候，开发环境下测试性能是非常重要的。在生产环境下新功能发布之前，通过真实用户测试性能特征是不可能的，所以在产品发布之前，开发环境测试以免性能降低是最好的方法。

真实环境

另一方面，虽然在开发环境下测试是测试性能的一种合理替代，但是这也并不一定反映了所有用户在你的网站上的体验。

用户设备的不同和用户网络质量好的好坏都会使得不同用户对应的网页性能差距很大。当然这还基于用户是否与页面交互或者如何与页面进行交互。

此外，加载的网页不一定是确定的。比如，一些加载个性化内容或者广告的网站的性能可能会因人而异。而开发环境并不能捕捉到这些不同。

指标类型

还有一些其他类型的指标和用户看待性能有关

• 感知加载速度： 页面加载并渲染所有可见元素到屏幕上的速度
• 加载响应度： 页面加载和执行JavaScript代码生成用来交互的组件的速度
• 运行时响应度： 页面加载完毕后，页面可以响应网页交互的速度
• 视觉稳定性： 网页元素是否不如用户期待那样移动了并且还潜在的干扰了用户的交互

鉴于以上所有类型的性能指标，我们可以清楚地意识到：没有一个单独的指标可以非常有效的捕捉到一个页面的所有性能特征。

重要的指标

• First Contentful Paint(FCP)：页面丛开始加载到任一元素渲染到屏幕上的时间。
• Largest Contentful Paint(LCP)：页面丛开始加载到最多的元素渲染到屏幕上的时间。
• First Input Delay(FID)：用户首次与页面交互(比如当点击链接或者一个按钮或者使用一个自定义的JavaScript驱动)到浏览器实际响应的时间。
• Time to Interactive(TTI)：页面从加载到进行视觉渲染并可能可靠响应用户输入的页面的时间。
• Total Blocking Time(TBT)：页面丛开始加载到任一元素渲染到屏幕上的时间。

自定义指标