浏览器之性能指标-TBT

1. 浏览器之性能指标-TTI

你能所学到的知识点

❝

1. 前置知识点
2. TBT 是个啥?
3. TBT 与 核心Web指标 的关系
4. TBT 得分
5. 如何测量TBT
6. 优化TBT

❞

好了，天不早了，干点正事哇。

RAIL 性能模型

RAIL 是一种以「用户为中心的性能模型」，它提供了一种考虑性能的结构。该模型将用户体验分解到按键操作（例如，点击、滚动、加载）中，帮助我们为每个操作定义性能目标。

RAIL 代表 Web 应用生命周期的「四个不同方面」：

1. 响应
   • 在 100 毫秒内完成由用户输入发起的响应，让用户感觉交互是即时的
   • 为了确保在 100 毫秒内产生可见响应，需要在 50 毫秒内处理用户输入事件
2. 动画
   • 在 10 毫秒或更短的时间内生成动画的每一帧
   • 从技术上来讲，每帧的最大预算为 16 毫秒（1000 毫秒/每秒 60 帧≈16 毫秒），但是，「浏览器需要大约 6 毫秒来渲染一帧，因此，准则为每帧 10 毫秒」
3. 空闲
   • 最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率
4. 加载
   • 在 5 秒内交付内容并实现可交互

用户对性能延迟的看法

核心Web指标

这个概念,我们在之前的文章中,其实有所涉及,并且我们后面也打算写一篇文章,专门介绍该概念. 不过,我们在这里还是在啰嗦一下.

核心Web指标是衡量Web上用户体验的重要指标。它们由三个指标组成，分别是

• 最大内容绘制时间（Largest Contentful Paint，LCP）
  • 衡量「加载性能」
  • 识别页面加载过程中主要内容最可能加载完成的时间点
• 首次输入延迟（First Input Delay，FID）
  • 衡量「交互性」
  • 评估用户需要等待多长时间才能与页面进行交互
• 累计布局偏移（Cumulative Layout Shift，CLS）
  • 衡量「视觉稳定性」
  • 总结可见页面内容布局中出现的意外变化

2. TBT 是个啥?

❝TBT:是Total Blocking Time的简写，中文名称总阻塞时间。 它是一个「实验室指标」，用于计算在FCP和TTI之间「主线程被阻塞的总时间」。 ❞

在页面加载过程中，从页面开始加载的时刻起，主线程负责处理不同的任务，比如解析HTML或处理JavaScript文件。

然而，有些任务需要花费足够长的时间，以至于用户会感受到明显的延迟。因此，「任何超过50毫秒的任务被认为是“长任务”」。这个阈值可能看起来是一个随意的设定，但它是基于RAIL性能模型的考虑。(关于主线程和长任务,我们在浏览器之性能指标-TTI有过介绍,这里就不在赘述)

当一个长任务正在处理时，浏览器无法简单地暂停它并响应用户的操作，比如用户的点击事件，而这些操作发生在长任务进行期间。

相反，浏览器必须等待「当前正在进行」的任务结束，才能响应用户的交互。

❝「超过50毫秒」阈值的任务部分被视为阻塞时间。 ❞

例如，如果主线程上的任务运行时间为60毫秒，则「长任务的阻塞时间」将等于10毫秒。

❝TBT是「所有长任务」的主线程阻塞时间的总和。 ❞

举个例子来说明，假设有两个长任务分别耗时60毫秒和80毫秒，你需要将它们的阻塞时间相加，分别为10毫秒和30毫秒。它们的总和为40毫秒，这就是你的TBT。

TBT VS TTI

TBT和TTI都是用来衡量页面加载响应性的「实验室指标」。

它们之间密切相关，当在优化过程中正确使用时，它们可以显著提升页面的响应性、交互性和可用性。

❝TBT是TTI的一个很好的「补充指标」，因为它有助于量化页面在变得可靠交互之前的非交互性的严重程度。 ❞

虽然TBT和TTI有着类似的目标，但它们在跟踪网页响应性方面存在不同。

TBT计算主线程在响应用户交互时被阻塞的时间，而TTI则衡量页面变得「完全可交互」所需的时间。

• TTI从FCP开始计时，直到页面完全可交互，即为大多数元素注册了事件处理程序，并在50毫秒内响应用户交互。
• TBT关注的是在FCP和TTI之间的「所有长任务的阻塞时间」。

另一个重要的区别是TBT以「毫秒为单位」进行测量，而TTI以「秒为单位」进行测量。

3. TBT 与 核心Web指标 的关系

虽然TBT不是核心Web指标，但TBT与其中一个指标——FID密切相关。

TBT和FID都「衡量页面的响应性」，也就是它们关注页面需要多长时间来加载和执行必要的资源，以便页面的元素能够快速响应用户的任何交互。

TBT和FID在测量加载响应性时的数据来源上有所不同，分别使用实验室数据和实际场景数据。

根据谷歌的官方文档，尽管FID是一个实际场景指标，但改进FID与优化TBT的建议密切相关，而TBT可以在「实验室环境」中测量。

因此，关注TBT和FID的优化建议，可以帮助提高页面的响应性和用户体验。

❝为了在实验室环境中预测FID，我们建议使用TBT。虽然它们衡量不同的内容，但通常TBT的改进与FID的改进是相对应的。 ❞

换句话说，由于他们之间,存在不可名状的关系.「你优化了TBT，你也将改善FID得分」。

还有一点需要额外关注，核心Web指标在网站排名中有着举足轻重的地位,进而我们可以得出,优化了FID可以让你网站排名考前.

❝这意味着，通过优化TBT我们可以优化FID得分，并间接影响我们网站搜索排名。 ❞

4. TBT 得分

由于TBT反映了页面从加载到页面响应的时间，因此我们的TBT得分越低越好，因为这样我们的用户将能够立即与页面内容进行交互。

更准确地说，我们应该将TBT得分目标设定为「低于200毫秒」。

以下是2023年的TBT得分准确阈值：

根据这些阈值，

• 当我们的TBT得分在0-200毫秒范围内时，被视为良好，可以用绿色来标识。
• 如果TBT得分在200-600毫秒之间，需要进一步改进，用橙色表示。
• 而当TBT得分超过600毫秒时，被认为较差，用红色标识。

需要注意的重要事项是，随着谷歌Lighthouse 8.0版本在2021年6月的更新，TBT的评分变得更加严格。

例如，在Lighthouse 6.0/7.0版本中，287毫秒的得分仍被认为是良好的。

然而，自从Lighthouse 8.0/9.0版本发布以来，良好的TBT得分被设定为低于200毫秒。

而最新版本的Lighthouse 10,虽然在TBT得分上没啥变化,但是在「权重」上有了更新.从之前的25%提升到30%.

想了解更多关于Lighthouse各个版本之间的差异,可以利用Lighthouse评分计算器窥探一番.

5. 如何测量TBT

TBT应该基于「实验室数据」进行分析。

虽然在实际场景中测量TBT是可能的，但并不推荐这样做，因为用户的交互可能会以各种方式影响页面的TBT，导致报告中出现大量的差异。

为了了解页面在实际场景中的交互性，我们应该测量FID和到下一次绘制的交互时间（Interaction to Next Paint，INP）。这两个指标更适合用于「衡量页面在实际场景中的响应性和交互性」。

基于上面的考量,以下是用于检查和分析TBT得分的「实验室工具」：

Chrome DevTools

想必大家在平时开发的时候,首选的浏览器应该是Chrome吧,2032年了,该不会有人还需要兼容IE吧.如果是,那秋风会带去我对你的同情.

以下是如何在Chrome DevTools中测量TBT的使用指南：

1. 打开Chrome DevTools：在我们想要分析的页面上右键单击，然后选择“检查”，或者在Windows系统上按Ctrl+Shift+I，Mac系统上按Command+Option+I。
2. 进入Performance部分并点击重新加载按钮，等待工具分析我们的页面。

3. 仔细查看生成的报告中的Main（主线程）部分。那些「右上角标价有红色小三角的灰色任务」就是长任务

1. 将鼠标悬停在这些任务上，可以查看特定任务阻塞主线程的时间。所有这些长任务的时间总和将计算出我们的TBT得分。

5. 如果需要更详细地了解「某个任务」的情况，我们可以查看下方的Bottom-up（自下而上）部分。

然后,我们就可以根据事件类型,采用对应的优化方式,将该长任务进行缩短.进而,缩短TBT

Lighthouse

另一种测量TBT的方法是运行Lighthouse。

要做到这一点，打开Chrome DevTools，然后进入Lighthouse。接着，点击Analyze page load按钮，等待Lighthouse收集数据并计算我们的得分。

我们还可以根据我们的喜好,还有想测量的侧重点,对测量的维度进行配置处理.

生成报告后，我们将在Metrics（指标）部分找到我们的确切得分，并按照对应的阈值颜色显示。

WebPageTest

WebPageTest通过提供确切的TBT得分并可视化主线程中的长任务，结合了Chrome DevTools和Lighthouse的功能。

要使用WebPageTest分析TBT，请进入该工具并选择主页上的Core Web Vitals（核心Web指标）选项卡。然后，输入我们想要分析的页面的URL(这里我们还是以字节跳动官网为例)。

这里多说一句,针对图中的第三步,可以选择桌面和移动端. 下面的数据我们选择了移动端的选项.

WebPageTest会在页面顶部的Observed Web Vitals Metrics中给出我们的TBT得分，还包括两个在实验室中也可以测量的核心Web指标度量——LCP和CLS。

要对长任务进行更详细的分析，我们可以在结果页面底部进入Total Blocking Time部分，查看阻塞主线程的长任务，这些任务按照脚本类型进行了组织。

通过点击长任务,我们就会新开一个页面,这就又到了Performance熟悉的页面了.

6. 优化TBT

在分析了我们的TBT得分之后，现在我们可以使用这些数据和工具来优化它。

作为一个起点，Lighthouse可以提供具体的建议来改善我们的TBT性能。

我们只需要向下滚动指标并在Diagnostics（诊断）部分筛选结果，这样审核结果将显示与TBT相关的指导意见。

具体的建议可能因页面问题而异，但它们都旨在减少我们页面的TBT，从而提升页面的响应性。

然而，总体而言，有四种主要方法可以改善我们的TBT得分：

上面给出的也是一种「指导意见」,而有时候,在实际项目中也会存在偏差,有一种「将在外,军令有所不受」的既视感,所以最好的解决方式-在既定的方针下,配合自己特有业务,对项目进行个性化处理.

后记

「分享是一种态度」。

参考资料：

1. TBT
2. RAIL 性能模型