目录
- Lighthouse 的总阻塞时间 (TBT) 是什么?
- 如何测量总阻塞时间
- 总阻塞时间和首次输入延迟有什么区别?
- 总阻塞时间和交互时间有什么区别?
- 总阻塞时间对性能有什么影响?
- 是什么导致总阻塞时间较长?
- 如何减少 WordPress 网站上超过 300 毫秒的总阻塞时间
我们都喜欢令人愉快、易于使用且快速的网站。为了确保提供出色的用户体验,您应该关注一些指标,TBT 就是其中之一。
更重要的是,作为一项用户体验指标, 总阻塞时间占 Lighthouse 计算的全局性能得分的 30%。这使其成为优化的首要指标!
我们将详细解释什么是总阻塞时间、为什么它相关、如何测量它以及哪些因素影响其分数。我们还将分享一些修复不良总阻塞时间等级(TBT 超过 300 毫秒)的提示,以提高您的整体性能分数并让您的访问者满意。
Lighthouse 的总阻塞时间 (TBT) 是什么?
总阻塞时间是一个重要的性能指标,用于衡量 WordPress 网站的负载响应能力。 当任务长度超过 50 毫秒时,它是首次内容绘制 (FCP) 和交互时间 (TTI) 之间的所有时间段的总和。 分数始终以毫秒表示。它占 Lighthouse 执行的总成绩的 30%。
Lighthouse 是一款开源自动化工具,可帮助开发人员提高网页质量。该工具考虑六个指标来生成最终性能得分,包括 核心网络指标、速度指数、总交互时间和总阻塞时间:
| 占比 | 好成绩(绿色的) | |
| First Contentful Paint | 10% | 0-2 s |
| Speed Index | 10% | 0-4.3 s |
| Largest Contentful Paint | 25% | 0-2.5 s |
| Time to Interactive | 10% | 0-5s |
| Total Blocking Time | 30% | < 300 ms |
| Cumulative Layout Shift | 15% | 0 – 0.1 |
💡如果您需要帮助来执行网站审核,我们建议您阅读我们的完整指南,其中解释了 如何提高您的 Lighthouse 性能分数。
如何测量 TBT 时间
您可以通过计算页面被阻止响应用户操作的总时间来衡量 TBT 分数。总数是通过将首次内容绘制 (FCP) 和交互时间 (TTI) 之间所有长任务的阻塞时间相加来计算的。
每个浏览器都有一个将代码转换为网页的过程。处理所有代码和样式的操作必须有效,因为我们希望尽快为访问者呈现页面。 (请记住,我们希望给人留下好印象并向用户展示我们的网站有多快!)
浏览器在渲染页面之前需要完成许多 任务 ,例如解析 HTML 脚本、构建网页 (DOM) 的结构和内容以及执行其 CSS 和 JS 代码。 (有很多事情要做,对吧?)
为了避免高阻塞时间, 浏览器在解析代码和渲染页面时不应遇到 JS 和 CSS 文件。为了让您的网站快速运行,我们必须“告诉”浏览器我们想要优先考虑什么以及我们想要首先加载什么。
了解长任务
如果任务运行时间超过 50 毫秒,则称为长任务并被视为“阻塞”。
在这种情况下,您的页面对用户输入(如屏幕点击、键盘按下、鼠标点击等)变得无响应。
总阻塞时间的计算是基于那些 长任务。长任务会显着垄断 Web 浏览器(> 50 毫秒)并阻止其他基本任务的性能(例如通过鼠标单击对用户操作做出反应)。任何时候存在 Long Task时,主线程都被视为“阻塞” 。计算机将每个请求的这个间隔记录为单独的阻塞时间。所有单独阻塞时间的总和称为总阻塞时间。
让我们看一个例子。每次 Lighthouse 检测到 长任务(>50 毫秒) 时,它也会测量阻塞持续时间:
正如您所看到的,总阻塞时间是通过添加不同长任务的“阻塞”部分计算得出的总和。长任务的阻塞部分是其持续时间超过 50 毫秒的部分(在我们的图表中为红色)。
让我们看一下另一个任务的分解来识别 TBT:
- 下面的时间线有五个任务,其中三个是长任务(持续时间 > 50 毫秒):
- 下图显示了每个长任务的阻塞时间,分别为 200 ms、40 ms 和 105 ms(总计:345 ms):
| TBT:FCP 和 TTI 之间发生的每个长任务(>50ms)的阻塞时间之和。 FCP:浏览器加载的第一个内容。这完全取决于用户的速度感知。 TTI:根据条件确定交互可以以令人满意的方式发生需要多长时间,至少 5 秒。 |
2 个测量总阻塞时间的工具
我们推荐两种不同的工具来衡量 TBT 和使用 Lighthouse 技术的表现。
- Google PageSpeed Insight (PSI):
这两种工具都提供 TBT 分数,但数字略有不同。这主要是由于多种因素造成的,包括 Lighthouse 实施、测试方法、测试地点等。
什么是好的总阻塞时间 (TBT) 分数?
您应始终努力使 TBT 小于 300 毫秒,以确保良好的用户体验。您的 TBT 分数只是您页面的 TBT 时间与数千个排名靠前的网站在移动或桌面上加载时的 TBT 时间的比较。
评分分类为:
- 绿色:0-300ms(快速)
- 橙色:300-600ms(中等)
- 红色:600+ms(慢)
总阻塞时间通常与 FID(首次输入延迟)指标相关。让我们看看为什么。
总阻塞时间和首次输入延迟有什么区别?
总阻塞时间和首次输入延迟之间的区别很简单:虽然总阻塞时间可以在没有真实用户的情况下计算,但首次输入延迟是一个仅字段指标,需要真实用户数据进行计算。
FID 计算无法在实验室环境中模拟。这种形式的数据来自多个来源,例如 Chrome 用户体验报告 (CrUX),其中收集的数据来自真实世界的用户。
当您的网站没有足够的“真实”数据来计算 FID 分数时,另一种方法是查看 在 实验室数据 部分测量的TBT 指标。 实验室数据具有基于一组固定网络条件从单个设备人工收集的数据。
TBT 和 FID 都以不同的方式衡量交互性并捕获用户对网站交互性和响应性的第一印象。
例如,GTmetrix 测试 TBT 而不是 FID,因为它使用合适的代理诊断几乎相同的优化:
通过优化总阻塞时间,您还可以 提高首次输入延迟分数(核心网络生命指标之一)——它们之间存在正相关性。当然,反之亦然。
如果您将 FID 保持在 100 毫秒以下,那么您的状态就很好:
总阻塞时间和交互时间有什么区别?
主要区别在于,交互时间衡量页面完全交互所需的时间 , 而总阻塞时间则告诉您 哪些 JS 任务 执行时间最长。
交互时间是与页面交互性相关的另一个指标。它是 Lighthouse 报告中跟踪的六个指标之一,用于衡量网站的性能。
测量 TTI 至关重要,因为有些网站 注重内容可见性 而牺牲了 实际交互性。这可能会造成令人沮丧的用户体验:用户认为网站已准备就绪,但当他尝试单击某处时,却没有任何反应。
如果主线程在大约 5 秒内没有处理长任务, TTI (下面的橙色)将页面标记为完全交互。
这是给你的一个测试。在下图中,您什么时候觉得可以互动?蓝色按钮什么时候在你的脑海中变得“可点击”?
您应努力将交互时间控制在 5 秒以内,以确保良好的用户体验。
总阻塞时间对性能有什么影响?
为了了解 TBT 对性能的影响,我们应该再次强调它在 Lighthouse Score 中的权重。
作为一项用户体验指标,TBT 目前占据全球性能得分的 30%。TBT 在 Lighthouse v5 中不存在,但现在在 Lighthouse v8 中占总成绩的 30%。TBT 测量您的网页被完全阻止、 阻止用户与页面的各个部分进行交互
的总时间 。这是一个重要的实验室指标,因为它定义了您的页面是否可用。
要使 TBT 保持在 300 毫秒以下,需要遵循几个基本原则,但首先,让我们看一下 TBT 不良的原因。
是什么导致总阻塞时间较长?
确定 TBT 分数超过 300 毫秒的原因有四个,即:
- 凌乱的 JavaScript 代码和未使用的 JS
- JS 执行时间长
- 高主线程工作
- 大量使用第三方代码
转到 Lighthouse 报告的机会和诊断部分将有助于确定您可以实施哪些解决方案:
该报告显示每个错误对您预计节省的影响有多大;解决这些问题将极大地提高您的 TBT 和网站的性能。
如果您想提高 TBT 分数,以下是需要解决的 PageSpeed Insights 建议列表:
- 删除(或减少)未使用的 Javascript
- 减少 JavaScript 执行时间
- 缩小 CSS 和 JS
- 消除渲染阻塞资源
- 减少第三方代码的影响
- 启用文本压缩
- 避免链接关键请求
- 避免巨大的网络负载
- 最小化主线程工作
如何减少 WordPress 网站上超过 300 毫秒的总阻塞时间
要修复超过 300 毫秒的 TBT 分数,您应该关注资源的顺序和加载首选项,以及请求的数量和大小。减少 WordPress 总阻塞时间的最有效方法是优化 JavaScript 文件(包括第三方代码)。
重要提示:任何促进 JS 执行的良好措施很可能会减少 TBT。
如果您想修复总阻塞时间并提高 WordPress 网站的速度,我们建议您实施八项性能优化。
- 推迟JS
- 延迟加载JS
- 预取 DNS 请求
- 缩小 JS
- 使用 GZip 压缩
- 缩小 CSS 文件
- 优化 CSS 递送
- 减少服务器响应时间和第一个字节的时间 (TTFB)
让我们看看具体操作。
1.延迟JS
延迟 JS 的意思是延迟 JS 加载到某个时间。在这种情况下,JS 文件将在浏览器显示最相关的内容后 加载 。通过延迟 JavaScript 文件,您可以加快 JavaScript 加载速度,这对于提高 WordPress 网站的性能非常宝贵。减少解析、编译和运行 JS 文件所花费的时间也有助于提高 TBT。
诊断部分的 Lighthouse 问题: 它解决了“消除渲染阻塞资源”、“删除未使用的 JavaScript ”和“避免链接关键请求”建议。
✅ 手动解决方案:
- 使用 Defer 属性: 当尝试延迟 JS 时,您可以在 HTML 中的 script 标签中使用布尔属性“defer”:
<script src=”code.js” defer></script>
JS 文件只有在页面的其余部分加载后 才会执行 。
✅ 使用 WordPress 插件:
- Asset CleanUp: 这个免费插件扫描并检测要加载到页面上的内容。编辑页面时,您只需选择没有用的 CSS 或 JS 代码即可。
重要提示:插件作者建议将 Asset CleanUp 与 WP Rocket 等缓存插件一起使用,以获得最佳结果。 - WP Rocket 有一个选项可以推迟 JavaScript 解析并推迟 JS WordPress 文件:
2.延迟JS
延迟 JavaScript 执行通过延迟加载所有 JS 文件直到发生用户交互(例如触摸屏幕、滚动或单击按钮)来提高性能和 TBT。
诊断部分的灯塔问题: 它解决了“避免链接关键请求”建议。
✅ 手动解决方案:
- 在JS中手动创建延迟的方法是使用setTimeout()方法函数。这将在您在ms中指定的时间之后调用函数 。您可以找到 非常有用的代码片段 来延迟任何 JS 函数,但这里有一个您可以遵循的示例:
假设您想要实现以下场景:
“用户点击按钮→等待2秒→页面将显示“Hello, How Are You?”:
<button onclick=”setTimeout(myFunction, 2000)”>Try it</button>
<script>
function myFunction() {
alert(‘Hello, How Are You? ‘);
}
</script>
✅ 使用 WordPress 插件:
- Flying Scripts:一个延迟 JS 并为关键 JS 文件提供更多资源的插件。它有助于确定优先顺序。
- WP Meteor:一个推迟 JS 脚本的插件,大大提高了访问者的感知速度(对于用户体验非常重要)。
- Gonzales:允许根据您访问的页面有条件地禁用 CSS、JS,甚至插件。
- Asset CleanUp (刚刚在上面的部分中提到)。
- WP Rocket :便捷的方式。您可以一键轻松延迟 JS 文件。
3. 预取 DNS 请求
DNS 预取是在请求资源之前尝试解析域名。
什么时候有用?如果您的网站上有第三方代码,例如 Vimeo 上托管的视频或某些 Google 字体。DNS 预取可以给您的网站带来一点提升,因为它将最大限度地减少来自其他网站的加载时间和资源。换句话说,DNS-prefetch 可以让您尽早连接到 第三方脚本,减少延迟并带来更高效的结果。
诊断部分的灯塔问题: 它解决了“减少第三方使用”和“预连接到所需来源”的建议。
✅ 手动解决方案:
- 在“head”部分使用“rel=dns-prefetch”。换句话说,您可以手动指定浏览器预取的域:
<button onclick=”setTimeout(myFunction, 2000)”>Try it</button>
<script>
function myFunction() {
alert(‘Hello, How Are You? ‘);
}
</script>
✅ 使用 WordPress 插件:
- Perfmatters 插件 具有 DNS 预取选项
- WP Rocket 插件在其 WordPress 仪表板中还有一个“预取 DNS 请求”部分:
4. 缩小 JS
缩小代码意味着删除任何混乱和无用的标点符号:新行、空格等。您可能总是有某种不需要的内容,并且会消耗大量时间,从而阻碍网页加载。通过从脚本中消除此类“死代码”,您可以为主线程腾出时间来专注于许多重要任务。
诊断部分的 Lighthouse 问题: 它解决了“减少 JavaScript 执行时间”、“最小化主线程工作”和“缩小 JS”建议。
✅ 手动解决方案:
- 备份您的站点,或者不要直接在生产服务器中编辑 JS 文件。
- 使用Sublime Text 或 Visual Studio Code等文本编辑器 。例如,我们不建议使用 Google 文档编辑代码 – 它会添加一些额外的格式。
- 打开包含代码的文件并删除注释、空格、换行符和缩进。不要忘记尽可能缩短 ID、类或变量名称并优化条件语句。
✅ 使用 WordPress 插件:
- Google 自己的Closure Compiler!它有助于 JS 压缩。
- Autoptimize 插件 还可以帮助您缩小 JS。
- WP Rocket 允许您一键缩小 JS 文件。
5.使用GZIP压缩
GZIP 压缩使您的代码能够被压缩,从而使从服务器发送到访问者浏览器的文件更小(并且您的网站速度更快!)您可以将所有 HTML、CSS 和 JS 压缩在一起以获得更小的文件,减少 TBT,从而提高性能。
诊断部分的 Lighthouse 问题: 它解决了“启用文本压缩”建议。
✅ 使用 WordPress 插件:
- 启用 GZIP 压缩 插件使您可以在 WordPress 网站上启用和禁用 Gzip 压缩。
- WP Rocket 自动启用 GZIP 压缩。您可以在我们的文档中阅读有关 GZIP 压缩的更多信息。
6. 缩小 CSS 文件
这可以通过删除注释、冗余代码和空格来减小文件大小。这个想法是,您希望尽可能减少时间,并且这些特征对于运行页面来说并不是必需的。这样做将减少 CSS 负载和整体解析时间。
诊断部分的 Lighthouse 问题: 它解决了“最小化主线程工作”和“最小化 CSS”建议。
✅ 手动解决方案(更多详情请参考上面的JS部分):
- 对站点进行备份,或者不要直接在生产服务器中编辑 CSS 文件。
- 使用Sublime Text 或 Visual Studio Code等文本编辑器 。
✅ 使用网络工具:
- 访问 minifycode.com 并单击 CSS minifier 选项卡。
- 将 CSS 代码粘贴到输入框中,然后单击“缩小 CSS”按钮。
✅ 使用 WordPress 插件:
- Autoptimize
- WP Super Minify
- CSS Nano
- WP Rocket 缓存插件可帮助您一键缩小 CSS:
7. 优化 CSS 递送
最小化主线程可以释放浏览器来处理网页高效运行所需的其他任务。某些事件(例如 CSS 解析)可能会阻止主线程处理其他任务和进程。因此,优化 CSS 的递送方式至关重要。
诊断部分的灯塔问题: 它解决了“最小化主线程工作”的建议。
✅ 手动解决方案:
- 合并并压缩您的 CSS 脚本
- 优先考虑首屏内容的 CSS 规则
- 避免在 HTML 正文中使用 STYLE 标记
✅ 使用 WordPress 插件:
- 借助“删除未使用的 CSS”选项,WP Rocket 缓存插件 可帮助您一键优化 CSS 交付。
8. 减少服务器响应时间和第一个字节的时间 (TTFB)
您的服务器需要速度快,并且您的 TTFB 需要优化以提高 TBT 分数。
诊断部分的 Lighthouse 问题: 它解决了“减少初始服务器响应时间”建议。
✅ 使用高级缓存插件和 CDN:
- WP Rocket 缓存插件和 CDN 将帮助您降低TBT分数。

发表回复