曾国藩,左宗棠,彭玉麟 并称大清三杰
曾国藩,左宗棠,彭玉麟,胡林翼并称中兴四大名臣 -<曾国藩传>

大家好，我是柒八九。

前言

最近,北京突发暴雨.部分地区,遭受洪灾,猛然发现,人在大自然中是何等的渺小.

同时,也希望大家能够平安度过此次天灾. 要相信,风雨之后,总会见彩虹.

---

今天我们来聊聊另外一个比较重要的性能指标TBT。

如果想了解该系列文章(浏览器底层原理&优化方案)，可以参考我们已经发布的文章。如下是往期文章。

1. 页面是如何生成的(宏观角度)
2. Chromium 最新渲染引擎–RenderingNG
3. RenderingNG中关键数据结构及其角色
4. 浏览器之客户端存储
5. 浏览器_知识点精讲
6. 像素是怎样练成的
7. 浏览器之资源获取优先级(fetchpriority)
8. 浏览器之性能指标_FCP
9. 浏览器之性能指标-LCP
10. 浏览器之性能指标-CLS
11. 浏览器之性能指标-FID
12. 浏览器之性能指标-TTI

你能所学到的知识点

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

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

---

1. 前置知识点

RAIL 性能模型

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

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

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

用户对性能延迟的看法

时间区间	描述
0 至 16 毫秒	用户非常关注轨迹运动，不喜欢不流畅的动画。每秒渲染60个新帧，用户认为动画很流畅。
0 到 100 毫秒	在此时间窗口内响应用户操作会让用户觉得结果是即时呈现的。操作与用户反应之间的联系不中断。
100 到 1000 毫秒	在此时间窗口内，用户会觉得任务进展基本上是自然连续的。对Web上的大多数用户来说，加载页面或更改视图是一项任务。
1000 毫秒或更长	超过1000毫秒（1秒），用户的注意力会从正在执行的任务上转移。
10000 毫秒或更长	超过10000毫秒（10秒），用户会感到失望，并且可能放弃任务。他们以后可能会回来，也可能不会再回来。

---

核心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毫秒	良好（绿色）
200-600毫秒	需改进（橙色）
超过600毫秒	较差（红色）

根据这些阈值，

• 当我们的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（主线程）部分。那些右上角标价有红色小三角的灰色任务就是长任务

4. 将鼠标悬停在这些任务上，可以查看特定任务阻塞主线程的时间。所有这些长任务的时间总和将计算出我们的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得分：

优化方向	措施
减少第三方代码的影响	尽管第三方插件(百度地图/视频播放器等)和分析脚本(sentry)是必不可少的，但它们都可能对页面加载性能产生负面影响。为了解决这个问题，可以识别慢速的第三方JavaScript，并通过使用async或defer属性、第三方CDN托管或Service Web Worker进行缓存来优化其服务方式。
减少JavaScript执行时间	为避免不必要的JavaScript加载和执行,为此，可以压缩、删除代码或将其拆分为较小的文件。
减少主线程工作	减少主线程工作时，应缩短其在解析、编译和执行CSS和JavaScript文件上所花费的时间。在优化过程中，可以考虑使用Web Workers、压缩和延迟非关键CSS、使用代码拆分或删除未使用的JavaScript代码。
减少请求资源数量和传输大小	通过选择CDN和优化CSS和JavaScript（专注于仅传送必要的代码），改进页面加载时间。

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

---

后记

分享是一种态度。

参考资料：

1. TBT
2. RAIL 性能模型

全文完，既然看到这里了，如果觉得不错，随手点个赞和“在看”吧。