浏览器之性能指标-TBT

简介: 浏览器之性能指标-TBT

1. 前置知识点

RAIL 性能模型

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

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

image.png

  1. 响应
  • 100 毫秒内完成由用户输入发起的响应,让用户感觉交互是即时的
  • 为了确保在 100 毫秒内产生可见响应,需要在 50 毫秒内处理用户输入事件
  1. 动画
  • 10 毫秒或更短的时间内生成动画的每一帧
  • 从技术上来讲,每帧的最大预算为 16 毫秒(1000 毫秒/每秒 60 帧≈16 毫秒),但是,浏览器需要大约 6 毫秒来渲染一帧,因此,准则为每帧 10 毫秒
  1. 空闲
  • 最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率
  1. 加载
  • 在 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的简写,中文名称总阻塞时间

它是一个实验室指标,用于计算在FCPTTI之间主线程被阻塞的总时间

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

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

image.png

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

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

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

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

TBT所有长任务的主线程阻塞时间的总和。

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

image.png


TBT VS TTI

TBTTTI都是用来衡量页面加载响应性的实验室指标

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

TBTTTI的一个很好的补充指标,因为它有助于量化页面在变得可靠交互之前的非交互性的严重程度。

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

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

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

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


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

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

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

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

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

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

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

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

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

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


4. TBT 得分

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

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

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

TBT得分 得分解读
0-200毫秒 良好(绿色)
200-600毫秒 需改进(橙色)
超过600毫秒 较差(红色)

image.png


根据这些阈值,

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

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

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

image.png


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

image.png


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

image.png

想了解更多关于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+IMac系统上按Command+Option+I
  2. 进入Performance部分并点击重新加载按钮,等待工具分析我们的页面。

image.png

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

image.png

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

image.png

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

image.png

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


Lighthouse

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

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

image.png

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

image.png


WebPageTest

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

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

image.png

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

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

image.png

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

image.png

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

image.png


6. 优化TBT

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

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

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

image.png

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

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

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

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


后记

分享是一种态度

参考资料:

  1. TBT
  2. RAIL 性能模型

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

相关文章
|
11月前
|
Web App开发 存储 JavaScript
浏览器之性能指标-TTI
浏览器之性能指标-TTI
206 0
|
11月前
|
Web App开发 存储 JavaScript
浏览器之性能指标-INP
浏览器之性能指标-INP
127 0
|
11月前
|
前端开发 JavaScript API
浏览器之性能指标-FID(二)
浏览器之性能指标-FID(二)
|
11月前
|
前端开发 JavaScript 搜索推荐
浏览器之性能指标-FID(一)
浏览器之性能指标-FID(一)
251 0
|
11月前
|
Web App开发 编解码 前端开发
浏览器之性能指标-CLS(二)
浏览器之性能指标-CLS(二)
257 0
|
11月前
|
前端开发 JavaScript UED
浏览器之性能指标-CLS(一)
浏览器之性能指标-CLS
225 0
|
11月前
|
存储 缓存 前端开发
浏览器之性能指标-LCP
浏览器之性能指标-LCP
114 0
|
11月前
|
Web App开发 缓存 前端开发
浏览器之性能指标_FCP(二)
浏览器之性能指标_FCP(二)
204 0
|
11月前
|
Web App开发 存储 前端开发
浏览器之性能指标_FCP(一)
浏览器之性能指标_FCP
148 0
|
12天前
|
JSON 移动开发 JavaScript
在浏览器执行js脚本的两种方式
【10月更文挑战第20天】本文介绍了在浏览器中执行HTTP请求的两种方式:`fetch`和`XMLHttpRequest`。`fetch`支持GET和POST请求,返回Promise对象,可以方便地处理异步操作。`XMLHttpRequest`则通过回调函数处理请求结果,适用于需要兼容旧浏览器的场景。文中还提供了具体的代码示例。
在浏览器执行js脚本的两种方式