目录
引子
在 Performance Guide 中介绍了以用户为中心的指导模型，接着看下在实际测量中的一些性能指标。原文 User-centric performance metrics 前段时间还在 Web Fundamentals 下，今天去看的时候变成了外链，但中文版还在 Web Fundamentals 下。以下是个人理解的部分翻译。
翻译时 User-centric performance metrics 原文 Last updated: Nov 8, 2019 。
正文
我们都听过性能有多重要。但当我们谈到性能和让网站“快速”时，我们具体指的是什么？
事实上性能是相对的：
- 一个站点对于一个用户（在一个有强力设备的快速网络上）来说可能是快速，但对于另外一个用户（在一个低端设备的慢速网络上）来说可能是慢速。
- 两个站点可能在完全相同的时间内完成加载，但其中一个似乎加载的更快（如果它逐步加载内容，而不是等到最后才显示任何内容）。
- 一个站点可能看起来加载很快，但之后对于用户的交互响应慢（或者根本没有响应）。
因此当谈到性能时，用精确并可以量化的客观标准来对其进行衡量，是很重要的。这些标准称为指标。
但是，仅仅因为一个指标是基于客观标准，并且可以定量测量，这并不一定意味着这些测量是有用的。
Defining metrics（定义指标）
在历史上，web 性能早期是通过 load 事件衡量。然而，尽管 load 在页面生命周期中，是一个定义良好的时刻，但这个时刻并不一定与用户关心的任何事情相对应。
例如，服务器可以用一个最小的页面来响应，该页面会立即触发 load 事件，但随后会异步获取页面中的所有内容并展示，这个过程可能是在 load 事件触发后好几秒发生。虽然这个页面在技术上拥有一个很快的加载时间，但这个时间与用户实际体验页面加载的情况不符。
在过去的几年，Chrome 团队成员与 W3C Web Performance Working Group 合作，一直致力于标准化一组新的 API 和指标，它们更准确地衡量用户如何体验 Web 页面的性能。
为了帮助确保指标与用户相关，我们围绕几个关键问题对它们进行了界定：
| 问题 | 描述 |
|---|---|
| Is it happening? | 导航是否成功启动？服务器响应了吗？ |
| Is it useful? | 有足够的内容提供给用户使用吗？ |
| Is it usable? | 用户可以跟页面交互吗，还是繁忙？ |
| Is it delightful? | 交互是否顺畅自然，没有滞后和干扰？ |
How metrics are measured（如何测量指标）
测量性能标准通常有以下方式：
- In the lab：使用工具在一致的受控环境中模拟页面加载
- In the field：真实用户实际加载和与页面交互。
这两个选项没有那一种一定比另一个更好或更差，事实上，为了确保良好的性能，这两种方式你通常都想使用。
In the lab（在实验室）
当开发新的功能，在实验室测试性能是有必要的。在产品发布新特性之前，不可能在实际用户身上测量它们的性能特性，因此在特性发布之前在实验室测试它们，是防止性能回归的最佳方法。
In the field（在现场）
另一方面，虽然实验室测试性能是一个合理方式，但它不一定反映所有用户在野外如何体验你的站点。
根据用户的设备功能和他们的网络情况，站点性能可能会有很大的变化。用户是否（如何）与页面交互同样会造成影响。
此外，页面加载可能是不确定的。例如，有加载个性化或广告的站点，用户之间可能会体验到截然不同的性能特性。实验室测试将不会捕捉到这些差异。
要真实的了解你的站点对于用户的性能表现如何，唯一的方法就是在用户加载和交互时测量它的性能。这种类型的测量通常称为 Real user monitoring ，简称 RUM 。
Types of metrics（指标类型）
还有一些其他类型的指标与用户如何感知性能相关。
- Perceived load speed ：一个页面加载并将其所有可视元素呈现到屏幕的速度。
- Load responsiveness ：一个页面加载和执行任何必需的 JavaScript 代码的速度，以便组件快速响应用户交互
- Runtime responsiveness ：页面加载后，页面响应用户交互的速度。
- Visual stability ：页面上的元素是否以用户不期望的方式移动，并可能干扰他们的交互？
- Smoothness ：转换和动画是否以一致的帧速率进行渲染，并从一个状态流畅地转变到下一个状态？
从以上提供的几种类型的性能指标中，可以清晰的知道，没有单一的指标能够捕获页面所有的性能特征。
Important metrics to measure（关键指标）
- First contentful paint (FCP) ：测量页面从开始加载到页面任何一部分内容渲染到屏幕上的时间。（lab，field）
- Largest contentful paint (LCP) ：测量页面从开始加载到最大文本块或图像元素渲染到屏幕上的时间。（lab，field）
- First input delay (FID) ：测量用户第一次与你的站点交互到浏览器实际可以响应该交互的时间。（field）
- Time to Interactive (TTI) ：测量从页面开始加载到可视化呈现、其初始化脚本（如果有的话）已加载，以及能够可靠快速地响应用户输入的时间。（lab）
- Total blocking time (TBT) ：测量 FCP 和 TTI 之间，长时间阻塞主线程导致阻碍输入响应的总时间。（lab）
- Cumulative layout shift (CLS) ：测量从页面开始加载到其生命周期状态变为 Hidden 之间发生的所有非预期布局移动的累积分数。（lab，field）
虽然此列表包含与用户相关许多不同方面的衡量标准，但并不包括所有方面（例如，当前未涵盖运行时响应性和平滑性）。
在某些情况下，将引入新的指标来弥补缺失的部分，但在其它情况下，最好的指标是专门为你的站点定制的。
Custom metrics（自定义指标）
上面列出的性能指标，有助于整体了解 web 上大多数站点的性能特征。它们还可以为站点提供一组通用的指标，以便将其性能与竞争对手进行比较。
然而，有时候在一些方面比较独特的站点，需要额外的指标来捕获性能全景图。例如，在 Largest contentful paint (LCP) 中，有可能最大的元素不是这个页面主要内容的一部分，因此 LCP 可能不相关。
为了应对这样的情况，Web Performance Working Group 还标准化了较低级别的 API，这些 API 对于实现自定义度量很有用：
- User Timing API
- Long Tasks API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- Server timing
可以在 Custom Metrics 中查看更详细的介绍。