前端性能指标解析

引言

前端性能是一个老生常谈的话题了，它不单单是一个技术概念，而是用户体验中非常重要的一环。通常在一些面向用户的产品中它直接影响了用户转化率、粘性等重要指标。

那么是不是不在乎转化率的中后台产品就可以不在乎性能了？显然不是，在中后台系统中虽然用户别无选择，但是糟糕的体验带给他们的压力会更大，且一定程度地影响他们的工作效率。

在消费者研究中指出，对网页加载速度延迟的压力反应类似于观看恐怖电影或解决数学问题，比在零售店排队等候的压力更大。

后面我会主要介绍前端的性能模型及其关键的性能指标，帮助大家更好定义自己系统的性能好坏。

性能模型

说到性能就不得不提到谷歌提出的 RAIL 模型 ，该模型是一种以用户为中心的性能模型，会将用户体验细分为关键操作（例如点按、滚动、加载），并帮助您为每项操作定义性能目标。

该模型定义了用户对性能的感知范围

基于该范围为每个方面都定了目标和准则：

• 相应：<50ms
• 动画：<10ms
• 空闲：最大限度地延长空闲时间
• 加载：3g 环境下 <5s

具体详细可以自行查看。类似灯塔和 Chrome DevTools 等性能分析工具也都是基于该模型去分析网页的性能数据，同时给出一些指标。接下来我们来详细了解这些效果指标。

效果指标

在了解具体指标之前我们要先了解效果指标的衡量方式，通过以下两种方式之一进行衡量：

• 在实验室中：使用工具在一致的受控环境中模拟网页加载，称之为实验室指标（lab）
• 在实际环境中：针对实际加载网页并与之互动的真实用户，称之为现场指标（field）

实验室指标

实验室指标通常需要借助开发工具，在一致受控的环境模拟加载。通常来说会在发布功能之前就行测试。

现场指标

和实验室指标不同，现场指标更多是在用户实际使用时采集的指标。

因为网站性能会因为用户的设备以及网络状态的不同造成明显的变化，还会受到用户的实际操作的不同而受到影响。

核心衡量指标

下面我们来介绍一些核心的衡量指标，所有指标会有自己的生命周期，同样地也会有指标被废弃

下面我会以 2024/02 的版本来介绍目前核心的三个指标：

Largest Contentful Paint (LCP)

 LCP最大内容绘制，为目前感知加载速度的最核心指标。他报告的时间区间为：

首次导航到相应网页的时间 => 视口中可见最大图片或文本块的呈现时间。

我们知道一个完整的周期包含很多过程：

而 LCP 记录在页面加载之后的时间，包含了后续的大部分 js 操作，是最能真实反应加载时长的指标。

何为最大内容？

和我们的固有印象不同，它记录的不是整个页面的“堆积”而是某个固定元素的大小，这个目标元素可能是

• 图片
• 视频
• 包含文本节点的块级元素

其“大小”指的是该元素在视图中占的尺寸。对于文本元素而言即块级元素所占的长方形区域，对于图片而言为调整过大小的可见尺寸或原尺寸（取小的），同时不包含 css 的边距。最终，占比最大的元素出现的时间点为上报的时间点。

要注意的是一旦用户操作，则会停止记录，当前记录的最大内容则为目标最大内容，之后再出现的不算。

如何评估好坏

RAIL 模型认为应将 LCP 控制在 2.5 秒以内，该指标取的是数据的 75 分位。

实际情况可以自己定义。比如相对于我们 Hulu 架构，目标相对激进，取的都是 90 分位数据，目标数字可能是 3s（good）、5s（need improvement）

Interaction to Next Paint (INP)

 和 LCP 一样  INP 也是一个核心指标，该指标用来评估页面的响应能力。INP 会在网页生命周期内观察用户与网页进行的所有点击、点按和键盘互动的延迟时间，并报告最长持续时间。

对于 INP，仅观察以下互动类型：

• 使用鼠标点击。
• 点按带有触摸屏的设备。
• 按实体键盘或屏幕键盘上的某个键。

这里需要注意的是INP 并不关心滚动本身，当然触发滚动的其他键盘操作可能会引起其他记录

同样的 75 分位 200ms 你的页面响应数据可以算得上优秀。

这里不得不提到另一个指标：First Input Delay (FID) 。FID 可以算得上 INP 的前任，不同的是其只记录页面上首次互动的输入延迟。相比来说 INP 更能反应整体水平。

Cumulative Layout Shift (CLS) 

累计布局偏移是最后一个核心指标，它可以量化用户遇到意外布局偏移的频率，越低代表体验越好。

什么是布局偏移？

突然插入的元素、布局的变化导致某些元素丢失其原来的位置，对于用户而言其关注的元素发生了位置变化。

举个例子：用户本来是要点击取消按钮提交按钮，突然插入的元素让用户不小心点到了提交。

CLS 会在每次布局偏移后记录其得分。得分计算方法了解下就好：

为了计算布局偏移得分，浏览器会考虑视口大小，以及视口中不稳定元素在两个渲染帧之间的移动。布局偏移分数是该移动的两种度量的乘积：影响分数和距离分数。

layout shift score = impact fraction * distance fraction

如何避免？

CLS 的优秀分数为 0.1 这个分数大家会没什么体感，且这个分数在我们团队不作要求。

我们中后台页面会有很多表单，折叠、开关等交互控制部分内容的显隐十分普遍。

大家只要注意以下场景即可。

• 没有尺寸的图片。
• 广告、嵌入和没有尺寸的 iframe。
• 动态注入的内容
• 网络字体。

其他衡量指标

其他指标多为非核心指标，这些指标要么被核心指标替代，要么包含在核心指标内，要么被废除，除了前面提到的 FID，我这里介绍些其余两个未被废除的重要指标：

Time to First Byte (TTFB)

TTFB 记录加载第一个字节所需时间，其包含了：

• 重定向时间
• Service Worker 启动时间（如果适用）
• DNS 查找
• 连接和 TLS 协商
• 请求，直到响应的第一个字节到达

无论是  FCP 还是 LCP 都包含了 TTFB 的时间，虽然他不是核心指标，但是在我们团队是一个非常关注的指标，他反映了我们整体 hulu 架构中天雀部分的性能水平。

 模型认为 75 分位的 800ms 为 GOOD ，而我们团队目前基本已经达到优秀水平，后续希望在 90 分位达到优秀水平。

First Contentful Paint (FCP)

First Contentful Paint (FCP) 是另一项重要指标。该指标很好理解，其报告区间为

 首次导航到相应网页的时间 => 网页的任何部分呈现在屏幕上所用的时间。

FCP 不会作为我们性能分析的核心数据，因为个人认为其上报的点不具有实际意义。同样以我们的 Hulu 架构为例，FCP 的上报时间大多在我们的 Layout 渲染期间，此时只渲染出了菜单，并没有开始渲染我们的微应用，我们可以轻而易举地达到 GOOD 水平，对于用户来说意义不大。当然它可以作为其他的过程指标，比如 layout 的渲染时间用于记录业务之前的渲染时长。

自定义指标

上面都是 RAIL 模型定义的指标，但就像我上面提到的，实际情况并不是所有指标都适用，我们还需要根据自己的实际情况，定制自己的指标。

比如我们的 Hulu 架构就有很多特点：

• spa 单页应用
• 中后台应用
• 多表单
• 微应用
• 可视化
• ...

针对这种情况，底层还是有很多 api 供我们使用的：

• User Timing API
• Long Tasks API
• Element Timing API
• Navigation Timing API
• Resource Timing API
• 服务器时间

具体这些 api 如何使用，本文就不多做介绍了，大家可以自行查阅。以及后续会有哪些自定义指标我会在后续的《性能标准》中体现。

最后

本文主要介绍了 RAIL 性能模型以及模型定义的相关指标，同时讲述了部分指标在团队内的使用情况。为什么要梳理这些？这些内容是我做性能优化以及制定目标的理论基础，同时也是我后续制订性能标准的重要参考。基于该模型也是希望能打造一个属于自己团队的性能模型，借此提高团队整体性能水位。

参考

使用 RAIL 模型衡量性能

注：HULU 是团队内基于 qiankun 改造的微前端架构，熟悉 qiankun 的可以将其带入更好理解。

作者：ES2049 / 某人

文章可随意转载，但请保留此 [原文链接](https://www.yuque.com/es2049/blog)。

非常欢迎有激情的你加入 [ES2049 Studio](https://es2049.studio/)，简历请发送至 [e-mail] 。