浏览器之性能指标-TTI

大家好，我是「柒八九」。

前言

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

你能所学到的知识点

❝

1. 前置知识点
2. TTI是个啥
3. 如何计算TTI
4. TTI 得分
5. 如何测量TTI
6. 什么原因导致 TTI 变慢？
7. 优化TTI

❞

1. 前置知识点

任务和主线程

一个任务是浏览器执行的任何「离散工作单元」。

任务包括

• 渲染、解析HTML和CSS
• 运行JavaScript代码
• 以及其他一些可能无法直接控制的工作

其中，编写并部署到网络上的「JavaScript是主要的任务来源之一」。

关于更多详细的内容，可以参考之前的像素是怎样练成的。这里不做展开。

上图是，在Chrome DevTools的性能分析器中，通过click事件处理程序触发的任务的描述

任务对性能有一些影响。

例如

• 在浏览器「启动期间」下载JavaScript文件时，它会「排队执行任务」来解析和编译该JavaScript，以便后续可以执行它。
• 在页面生命周期的「后期阶段」，当你的JavaScript执行工作，比如通过事件处理程序驱动交互、JavaScript驱动的动画以及诸如分析数据收集等后台活动时，也会触发任务。
• 除了Web Workers和类似的API之外，所有这些都在主线程上执行。

主线程

在浏览器中，大部分任务都在主线程上运行。它被称为主线程有其原因：几乎所有你编写的JavaScript代码都在这个线程上执行。

「主线程一次只能处理一个任务」。当任务的执行时间超过一定阈值（50毫秒）,它们被归类为「长任务」。如果用户在长任务执行时尝试与页面进行交互，或者需要进行重要的渲染更新，浏览器将延迟处理这些工作。这导致交互或渲染延迟。

❝可以将主线程视为餐厅里的服务员。服务员需要接受订单、处理付款、送上食物、加满饮料等等。 ❞

如果服务员被某个任务拖累，比如花费太长时间处理订单（例如，客户点餐很复杂或犹豫不决），服务员就无法处理其他任务。

在Chrome的性能分析器中，「长任务」通常以「红色三角形」的形式呈现。任务的阻塞部分会被填充上带有「红色斜线图案的纹理」，以示区别。

你需要拆分任务。这意味着将一个长任务分割成较小的任务，使它们在单独运行时所需的时间更短。

一个长任务VS将同一个任务拆分成五个较短任务

当任务被拆分时，浏览器有更多机会「响应更高优先级」的工作，其中包括用户的交互操作。

当任务过长且浏览器无法快速响应交互时VS将较长任务拆分成较小任务后的交互情况

在上述图例的顶部，由用户交互触发的事件处理程序「必须等待一个长任务完成后」才能执行，这导致交互延迟。而在底部，事件处理程序「有机会更早地执行」。由于事件处理程序有机会在较小的任务之间运行，它比等待长任务完成时运行要更快。

由于长任务的出现，它们可能会延迟FCP和TTI。在顶部的示例中，用户可能会感觉到延迟；而在底部，交互可能会感觉瞬间完成。

页面完全可交互

"页面完全可交互"（Page Fully Interactive）是指在网页加载完成后，「所有」主要的用户交互元素和功能都已经加载并且可以响应用户的操作，用户可以在页面上执行各种操作而不会出现明显的延迟或等待。当页面完全可交互时，用户体验更加流畅，因为用户可以立即与页面进行交互，无需等待页面响应。

当一个网页达到页面完全可交互的状态时，以下几个条件应当满足：

1. 「页面结构已经完全加载：」 所有HTML文档、CSS样式表和JavaScript脚本都已下载完成，并且浏览器已经解析和构建了整个页面的DOM结构。
2. 「主要内容可见：」 网页的主要内容已经在浏览器窗口中可见，用户可以看到页面的核心信息而不需要进行滚动或等待。
3. 「用户交互元素可用：」 网页上的按钮、链接、表单等交互元素都已加载并且可以正常响应用户的点击、输入或其他操作。
4. 「动态功能可用：」 如果网页中有使用JavaScript实现的动态功能，如下拉菜单、轮播图等，这些功能也已经可以正常使用。
5. 「响应时间短：」 当用户执行交互操作时，网页的响应时间非常短，用户几乎感觉不到延迟。例如，点击按钮立即有响应，页面切换或动画流畅运行。

2. TTI是个啥

❝TTI:是Time to Interactive的简写，中文名称可交互时间。 ❞

它用于衡量「网页加载完成后，用户可以与页面进行交互的时间」。它是页面加载过程中的一个关键度量标准，更准确地反映了用户实际体验的时间点。

❝页面的可交互性通过以下四个标准来衡量：

1. 浏览器显示「有意义」的内容
2. 页面已准备好处理用户针对「可见元素的操作」
3. 页面在「50毫秒内响应用户交互」
4. 页面代码中最重要的脚本已被执行，使「主线程处于空闲状态」

❞

重要的是要理解，TTI不仅仅衡量页面的加载时间，同时也专注于页面的可交互性。

加载时间 vs 可交互性

加载时间与可交互性是网页性能的不同但相关的两个性能指标。

• 加载时间描述了加载网站内容所需的时间
• 可交互性描述了网站变得响应的时间

这听起来可能像是在比较两个同义词，但实际上它们之间的区别非常重要。

举一个比较贴切的例子：在周一早上，你被闹钟吵醒了，然后从生理上，睁开眼睛，然后来床上各种伸懒腰，这一系列的操作可以认为，你是为了迎接一天的工作的「暴击」做的前期准备，也就是说，你的身体正在加载。然而，此时的你，衣服没穿，脸没洗，牙没刷的你，是还没有到到工作状态。无法及时响应老板给你「画的大饼」。你还需要一顿早餐的补给，才可以完全响应老板的各种工作指派。也就是说，你只有在此时才处于 「完全响应」老板的工作。

❝TTI是一种「以用户为中心的指标」，侧重于从客户的实际角度评估网页性能。 ❞

为了使用户留在一个网站上，在页面加载过程中必须迅速地发生四个关键时刻。

1. 首先，用户收到一个可见的信号，表示页面正在加载中。
2. 其次，加载的内容变得足够有用，以便理解页面的内容。
3. 在第三步中，页面变得「可交互」。
4. 最后，页面「完全可交互」，意味着用户可以顺畅地进行交互，没有中断。

我们可以将TTI视为一种检查网站提供用户满意的体验所需时间的方式，其满意体验主要表现在「感知速度」方面。通过控制这个时间，我们可以降低跳出率并给用户留下良好的印象。

TTI 是核心网络指标吗？

TTI不是核心网络指标（Core Web Vitals）的指标。核心网络指标是一组用于衡量用户体验不同方面的三个指标。其中，

• LCP（最大内容绘制时间）衡量感知「加载速度」
• FID（首次输入延迟）衡量「响应性」
• CLS（累积布局偏移）衡量「视觉稳定性」

这三个指标被认为是评估网站用户体验的关键要素。

其他网络关键指标不在核心网络指标范畴内，但它们提供有关网站速度的额外信息。

TTI可能不是核心网络指标的候选指标，并且可能不会影响我们在谷歌搜索中的排名。但仍然值得使用这个指标。一个良好的TTI分数可以降低CLS，并且TTI仍然是衡量用户在访问初期对网站的感知的相关指标。

3. 如何计算TTI

TTI的「计量单位是秒」，计算页面的TTI需要识别FCP和首个5秒「静默窗口」(Quiet Window)。

在这个窗口中，浏览器不应处理主线程上「超过50毫秒的任何任务」，也不应等待「超过两个服务器响应请求」。

❝TTI是FCP和「静默窗口」之间的一个时间点，它恰好位于「静默窗口之前」的最后一个「长任务完成」时。 ❞

TTI 起始点

计算TTI分数的第一步是找到我们网站的FCP。

FCP是一个指标，用于标识页面加载时间轴上用户可以在屏幕上看到「任何内容的第一个点」。较短的FCP给用户一种，你的页面正在加载的赶脚。同时，他会下意识的认为，他想要的页面内容，马上就要「呼之欲出」了。

有里有一个小的提示点：不要将FCP与LCP混淆。LCP是一个性能指标，用于确定网页上「最大元素」在用户浏览器中变为可见的时间。

下图，简单的为我们展示了FCP、LCP和TTI在页面加载中，可能存在的位置和方式。

❝LCP总是在页面完全可交互之前准备好，但它不影响TTI指标的计算。 ❞

TTI 结束点

在我们网页加载过程中,用户的浏览器会执行许多脚本。其中一些任务需要的时间「超过50毫秒」，并且这些任务与TTI的测量相关。浏览器还会异步地向服务器「发送资源请求」，并且每个请求都会保持open状态，直到获得响应。

有一个时刻，浏览器可以休息一下，我们称之为「静默窗口」(quiet window)。

❝这是在至少五秒内，浏览器不需要在主线程上执行任何长时间任务，并且最多只有2个资源请求处于"open状态的第一个时刻。 ❞

有一点可以确定，FCP总是在静默窗口之前发生的。

确定 TTI 得分

在这个时间范围内，我们应该寻找一个时刻，即浏览器在「静默窗口之前」完成了「最后一个长时间任务」。

如果FCP后「没有任何超过50毫秒的任务」，我们的TTI等于我们的FCP。

TTI vs FID

• FID衡量的是网页在FCP和TTI之间对「用户交互作出响应所需的时间」。
• TTI衡量的是「页面完全可交互所需的时间」，而不是页面对用户操作作出反应所需的时间。

4. TTI 得分

和其他性能指标一样,TTI也存在好坏阈值.

根据Lighthouse中TTI 的阈值如下：(这里有很多版本,我们采用市面上常见的版本)

• 良好 - 无需处理 = TTI 小于或等于 2.5 秒。
• 可以接受，但考虑改进 = TTI 在 2.5 秒到 3.2 秒之间。
• 超出推荐时间 = TTI 在 3.2 秒到 4.5 秒之间。
• 远远超出推荐时间 = TTI 高于 4.5 秒。

5. 如何测量TTI

测量TTI的最佳方法是在网站上运行Lighthouse性能审核。

然而，目前，谷歌正在改变其Lighthouse 10工具，将TTI从中移除，并将其得分权重转移到CLS。CLS现在将占据整体性能得分的25%，而TTI将构成该部分的10%。

作为测量TTI的替代工具有：

• WebPageTest
• Lighthouse 老版本 (这里不做展示了)

使用Webpagetest测量TTI

打开Webpagetest网站，然后输入我们想要测试的URL。（这里我们以字节跳动官网为例）

在经过一段时间后，Webpagetest会给出我们详细的针对网站的各个指标的数据。其中有很多我们熟悉的老朋友。(LCP/FCP/CLS等)

如果我们想查看TTI得分，我们需要点击Plot Full Results按钮，因为在第一个结果屏幕上不会显示该得分。

向下滚动以查找TTI指标。

6. 什么原因导致 TTI 变慢？

巨大的网络负载大小

FCP是在页面上出现第一个“有意义”的元素时触发的。无论这个元素是什么类型的，如果在该元素之上嵌入了「阻塞渲染的资源」，例如指向大文件的 <script> 或 <link> 标签，这些资源会因为在不太好的网络连接下下载而导致显示被延迟。

为了解决这个问题，建议优化代码，使其更“轻量”，通过尽可能减小文件大小，同时在可能的情况下脱离第三方库的依赖。

页面加载时包含过多的 JavaScript

基于这一点,其实我们之前在讲FCP/LCP中多次提到,就是JS的「按需加载」.我们应该秉承一个原则- 「吃多少,拿多少」,不要胡吃海喝,这样对胃不好.我们可以只加载,当前视图中所用到的JS,而不贪杯.

同时进行多个网络请求

最后但同样重要的是，网络请求的数量是一个需要考虑的重要因素。

图片不会阻塞渲染。这意味着如果浏览器在解析 HTML 文件时遇到一个 <img> 标签，它会开始加载图片，并继续处理后续标签，而不必等待图片完全加载。这一点起初听起来可能很好。

另一方面，这也会导致页面上同时加载大量非优化的图片，这很可能需要更多时间来加载并保持这些请求连接打开，从而延长页面的TTI.

从上面的多个角度,我们得到一个结论:

❝TTI缓慢主要是由现代网站普遍使用的大量JavaScript引起的。 ❞

长时间的JavaScript任务，即执行时间「超过50毫秒的任务」，会占用主线程的大量时间，从而延迟TTI的发生。

由于浏览器「依赖主线程」来完成各种任务，长时间的任务会使页面在任务完成之前变得不响应。

7. 优化TTI

要提高TTI，有两个关键因素需要考虑

1. 优化JavaScript代码
2. 减少服务器响应时间

优化JS

• 优化我们的代码，对未使用的脚本进行缩小，
• 压缩找到的最大文件
• 不要通过将所有JavaScript代码发送到一个文件中来使浏览器不堪重负，而是将代码拆分，并最初只发送访问者在开始时所需的必要代码
• 延迟加载第三方脚本，如社交分享按钮、视频播放器嵌入、广告的iframes等，同时优先处理对用户提供最大价值的脚本
• 使用defer属性告知浏览器不要等待特定的脚本，而是继续处理HTML

❝上面的一些优化方法,我们之前也有讲过,这里就不在过多解释了. ❞

减少服务端反应时间

• 使用内容分发网络（CDN），将内容存储在靠近用户的服务器上
• 应用预取技术，例如提前渲染特定页面元素
• 避免使用生成额外HTTP请求的网络字体资源

参考资料：

1. CLS优化
2. 优化长任务
3. TTI