总阻塞时间（tbt）是lighthouse关键性能指标，量化fcp到tti间所有长任务（＞50ms）超出50ms部分的总和，反映页面对用户输入累计失联时长；其值越低，交互响应越及时。

总阻塞时间（Total Blocking Time，TBT）直接反映页面在关键加载窗口内对用户输入“失联”的程度——它不是看有没有卡，而是看卡了多久、累计多严重。核心在于：TBT只统计从首次内容绘制（FCP）到可交互时间（TTI）之间，所有长任务（>50ms）超出50ms门槛的那部分时间之和。

明确TBT的测量范围和触发条件

TBT不覆盖整个页面生命周期，只聚焦用户最敏感的过渡阶段：

• 起点是FCP：页面已渲染出第一块有意义的内容，用户开始有视觉反馈
• 终点是TTI：主线程连续5秒无长任务，页面被判定为“稳定可交互”
• 只计入该区间内每个 >50ms 的任务中，超出50ms的部分（例如110ms任务贡献60ms TBT）
• 短任务（≤50ms）不计入，无论数量多少——它们通常不会造成可感知卡顿

理解TBT背后的主线程行为逻辑

TBT本质是主线程过载的量化体现。浏览器主线程需串行处理脚本执行、样式计算、布局、重绘等任务。一旦某项任务耗时过长，就会把后续输入事件（点击、滚动、键盘）排队挂起，直到它完成。

• 一个180ms的JavaScript解析+执行任务 → 直接贡献130ms阻塞时间
• 连续三个60ms的任务 → 每个贡献10ms，TBT合计30ms
• 若某次渲染因强制同步布局（layout thrashing）触发多次重排 → 可能拆成多个长任务，叠加TBT

用Lighthouse定位高TBT的具体来源

Lighthouse报告中的“Diagnostics”和“Opportunities”板块会直接关联TBT成因：

• 查看“Reduce JavaScript execution time”建议：识别执行时间最长的脚本文件及函数调用栈
• 检查“Minimize main-thread work”下的任务分类：哪些样式计算、布局或JS解析占用了大量连续时间
• 结合Performance面板录制：筛选Main线程轨迹，按Duration倒序，标出所有>50ms的条目并观察上下文（是否在React渲染、第三方SDK初始化、图片解码后处理等环节）

区分TBT与关联指标的实际意义

TBT常与FID、TTI一起出现，但角色不同：

• FID是真实用户第一次点击时遭遇的延迟（仅测单次），而TBT是FCP→TTI全程所有阻塞的总和，更全面反映“不可响应期”的负荷密度
• TTI是时间点（页面何时变可靠），TBT是时间段积分（这期间有多难熬）；TBT升高往往直接推迟TTI
• CLS关注视觉跳动，LCP关注首屏加载，TBT专注交互就绪前的“等待成本”——三者共同构成用户对“快”与“顺”的完整判断