曾国藩,左宗棠,彭玉麟并称大清三杰
曾国藩,左宗棠,彭玉麟,胡林翼并称中兴四大名臣 -<曾国藩传>
大家好，我是柒八九。
前言
最近,北京突发暴雨.部分地区,遭受洪灾,猛然发现,人在大自然中是何等的渺小.
同时,也希望大家能够平安度过此次天灾. 要相信,风雨之后,总会见彩虹.
今天我们来聊聊另外一个比较重要的性能指标TBT。
如果想了解该系列文章(浏览器底层原理&优化方案)，可以参考我们已经发布的文章。如下是往期文章。
- 页面是如何生成的(宏观角度)
- Chromium 最新渲染引擎--RenderingNG
- RenderingNG中关键数据结构及其角色
- 浏览器之客户端存储
- 浏览器_知识点精讲
- 像素是怎样练成的
- 浏览器之资源获取优先级(fetchpriority)
- 浏览器之性能指标_FCP
- 浏览器之性能指标-LCP
- 浏览器之性能指标-CLS
- 浏览器之性能指标-FID
- 浏览器之性能指标-TTI
你能所学到的知识点
- 前置知识点
TBT是个啥?TBT与核心Web指标的关系TBT得分- 如何测量
TBT- 优化
TBT
好了，天不早了，干点正事哇。
1. 前置知识点
RAIL 性能模型
RAIL 是一种以用户为中心的性能模型，它提供了一种考虑性能的结构。该模型将用户体验分解到按键操作（例如，点击、滚动、加载）中，帮助我们为每个操作定义性能目标。
RAIL 代表 Web 应用生命周期的四个不同方面 ： 
响应- 在
100 毫秒内完成由用户输入发起的响应，让用户感觉交互是即时的 - 为了确保在 100 毫秒内产生可见响应，需要在 50 毫秒内处理用户输入事件
- 在
动画- 在
10 毫秒或更短的时间内生成动画的每一帧 - 从技术上来讲，每帧的最大预算为
16 毫秒（1000 毫秒/每秒 60 帧≈16 毫秒），但是，浏览器需要大约 6 毫秒来渲染一帧，因此，准则为每帧 10 毫秒
- 在
空闲- 最大限度增加空闲时间以提高页面在
50 毫秒内响应用户输入的几率
- 最大限度增加空闲时间以提高页面在
加载- 在 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的简写，中文名称总阻塞时间。
在页面加载过程中，从页面开始加载的时刻起，主线程负责处理不同的任务，比如解析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的使用指南：
-
打开
Chrome DevTools：在我们想要分析的页面上右键单击，然后选择"检查"，或者在Windows系统上按Ctrl+Shift+I，Mac系统上按Command+Option+I。 -
进入
Performance部分并点击重新加载按钮，等待工具分析我们的页面。
3. 仔细查看生成的报告中的Main（主线程）部分。那些右上角标价有红色小三角的灰色任务 就是长任务 
- 将鼠标悬停在这些任务上，可以查看特定任务阻塞主线程的时间。所有这些长任务的时间总和将计算出我们的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（专注于仅传送必要的代码），改进页面加载时间。 |
上面给出的也是一种指导意见 ,而有时候,在实际项目中也会存在偏差,有一种将在外,军令有所不受的既视感,所以最好的解决方式-在既定的方针下,配合自己特有业务,对项目进行个性化处理.
后记
分享是一种态度。
参考资料：
全文完，既然看到这里了，如果觉得不错，随手点个赞和"在看"吧。
