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
,从而提升页面的响应性。
然而,总体而言,有四种主要方法可以改善我们的TB
T得分:
优化方向 | 措施 |
减少第三方代码的影响 | 尽管第三方插件(百度地图/视频播放器等 )和分析脚本(sentry )是必不可少的,但它们都可能对页面加载性能产生负面影响。为了解决这个问题,可以识别慢速的第三方JavaScript,并通过使用async 或defer 属性、第三方CDN 托管或Service Web Worker 进行缓存来优化其服务方式。 |
减少JavaScript执行时间 | 为避免不必要的JavaScript加载和执行,为此,可以压缩 、删除代码 或将其拆分为较小的文件。 |
减少主线程工作 | 减少主线程工作时,应缩短其在解析、编译和执行CSS和JavaScript文件上所花费的时间。在优化过程中,可以考虑使用Web Workers 、压缩 和延迟非关键CSS 、使用代码拆分或删除未使用的JavaScript代码。 |
减少请求资源数量 和传输大小 |
通过选择CDN 和优化CSS和JavaScript(专注于仅传送必要的代码),改进页面加载时间。 |
上面给出的也是一种指导意见,而有时候,在实际项目中也会存在偏差,有一种将在外,军令有所不受的既视感,所以最好的解决方式-在既定的方针下,配合自己特有业务,对项目进行个性化处理.
后记
分享是一种态度。
参考资料:
全文完,既然看到这里了,如果觉得不错,随手点个赞和“在看”吧。