布局没崩却点不动：用 TBT 和主线程占用排查响应式页面的 JS 交互卡顿

页面看起来一切正常：按钮位置没有偏移，菜单也没有错位，响应式断点在手机和桌面端都工作正常。但用户点击按钮后要等一会儿，导航菜单展开时像被“卡住”，连续点击还可能出现操作堆积。这类问题通常不是布局崩溃，而是浏览器主线程正在忙于执行 JavaScript，暂时没有时间处理输入事件。

TBT 反映了什么

Total Blocking Time（TBT）是实验室性能指标，用来统计页面从首次内容绘制到可交互阶段之间，主线程被长任务阻塞的总时间。一个主线程任务如果执行时间超过 50 毫秒，就会被视为长任务；TBT 只计算超出这 50 毫秒的部分。

例如，一个任务持续 220 毫秒，浏览器会把前 50 毫秒视为任务本身的正常执行区间，剩余 170 毫秒则计入 TBT。任务运行期间，浏览器很难及时响应点击、键盘输入等用户操作，因此 TBT 偏高时，页面常常会表现为“看得到，但点不动”。

TBT 不是实际用户现场采集的核心网页指标，但它对排查主线程阻塞很有帮助。交互体验相关的现场指标是 INP，而 TBT 更适合在 Lighthouse、PageSpeed Insights 或性能录制中定位问题来源。资料中常见的实验室参考值是：TBT 不超过 200 毫秒通常属于较好的范围，但这个数值应作为诊断参考，而不是替代真实用户数据。

为什么布局正常也会卡

浏览器主线程承担的工作不只有布局。它还要解析 HTML 和 CSS、解析与编译 JavaScript、执行脚本、处理事件、计算样式、更新布局并参与绘制。当这些工作连续占满主线程时，页面的几何结构可以保持稳定，点击却仍然无法立即得到反馈。

所以，“页面没有发生位移”只能说明布局稳定性可能没有明显问题，不能证明交互顺畅。按钮的点击事件可能已经进入等待队列，只是要等当前任务结束后才能执行。

先找长任务，再看事件监听

排查时不要一开始就猜是某个框架或某个插件导致卡顿。先录制一次真实的交互过程，确认点击发生前后主线程到底在做什么。

在浏览器开发者工具的 Performance 面板中，可以按下面的顺序操作：

1. 打开性能录制面板，开始录制页面加载或具体交互。
2. 重新加载页面，等待初始内容出现。
3. 点击有延迟的按钮，展开菜单，或重复触发出现卡顿的操作。
4. 停止录制，查看主线程时间线中的长任务。
5. 展开长任务，确认它是脚本执行、事件回调、样式计算、布局，还是其他浏览器工作。
6. 记录任务的调用来源，以及它发生在初始加载、点击事件还是菜单展开过程中。

长任务本身不是结论。关键是看它由什么代码触发，以及它是否正好覆盖了用户输入发生的时间点。初始化脚本、页面构建器生成的交互代码、分析脚本、菜单组件初始化和大批量 DOM 操作，都可能出现在这条链路中。

如果卡顿只发生在点击之后，优先展开对应的事件回调。重点检查回调中是否同步执行了大量计算、遍历了大范围 DOM，或者一次性创建、修改了很多节点。若长任务在页面加载时就出现，则应先关注初始化脚本是否把非必要工作集中放在了首屏阶段。

不要只看 JavaScript 文件大小

一个 JavaScript 文件传输体积不大，并不代表它一定不会造成交互卡顿。文件下载完成后，浏览器还要解析代码、编译代码并执行代码。代码体积只是网络传输维度，解析和执行时间则是主线程维度。

例如，一个脚本可能经过压缩，下载速度也很快，但启动时仍然会同步注册大量事件、遍历页面节点、读取配置并初始化多个组件。对用户来说，影响点击响应的是这些工作占用了多久，而不是文件在网络面板中显示了多少 KB。

在 WordPress 页面中，主题脚本、插件脚本和页面构建器生成的脚本可能同时参与初始化。与其笼统地判断“插件太多”，不如在性能时间线中确认具体脚本是否产生了长任务，再决定是延后初始化、减少执行范围，还是拆分业务逻辑。

第二步检查布局抖动和频繁重排

长任务定位后，还要确认其中是否混入了布局抖动。布局抖动通常发生在代码反复交替读取布局信息和修改布局状态时。

下面这种写法容易让浏览器频繁重新计算布局：

items.forEach((item) => {
  const height = item.offsetHeight;
  item.style.height = `${height + 10}px`;
});

代码一边读取 offsetHeight，一边修改元素的高度。元素数量较多或结构较复杂时，浏览器可能反复进行样式计算和布局更新，最终把本来简单的点击操作拖成长任务。

更稳妥的做法是先集中读取，再集中写入：

const heights = items.map((item) => item.offsetHeight);

items.forEach((item, index) => {
  item.style.height = `${heights[index] + 10}px`;
});

这并不意味着所有布局读取都会造成问题，而是要避免在循环中不断交替读写。调试时可以观察 Performance 面板里的样式计算和布局记录：如果一次交互中出现大量重复的布局工作，就要回到事件回调和 DOM 操作处检查。

菜单展开尤其容易触发这类问题。常见风险包括：

• 点击一次后遍历整个导航树；
• 展开一个菜单时同步测量多个隐藏面板的尺寸；
• 修改类名后立刻读取元素宽高；
• 对大量列表项逐个设置会影响布局的样式；
• 在滚动、调整窗口大小或指针移动事件中持续执行布局计算。

如果动画只是改变元素的尺寸或位置，可以优先确认是否能通过更少的布局操作完成。对于需要持续触发的事件，也要检查是否存在无节制的同步回调，而不是简单把所有问题归因于 CSS 动画。

第三步区分运行时和业务代码

当长任务确认存在，但代码来源比较复杂时，再区分框架运行时开销与业务代码问题。这里的重点不是比较哪个框架更快，而是找出当前页面真正执行了什么。

框架运行时或组件系统可能在交互时完成状态更新、组件重新渲染、依赖计算和 DOM 对比。如果一次状态变化意外导致大范围组件更新，主线程就可能出现明显的长任务。排查时可以观察点击一个小按钮后，是否有远超预期的组件或节点参与更新。

业务代码则常见于这些位置：事件回调中执行大数组处理、菜单打开时重新生成整棵 DOM、每次交互都重复解析数据，或者在页面初始化阶段立即启动并不影响首屏的功能。它们即使没有使用复杂框架，也同样会阻塞主线程。

可以用三个问题快速分界：

1. 长任务的调用栈是否主要落在框架运行时代码中？
2. 业务事件是否触发了大范围组件更新或 DOM 修改？
3. 删除某个初始化分支、缩小更新范围后，长任务是否明显减少？

如果主要问题是更新范围过大，应缩小状态影响的组件边界，避免一个菜单状态变化导致整页重新计算。如果主要问题是业务回调本身过重，则应拆分任务，把不需要立即完成的工作延后或分段执行。对于确实需要连续处理的异步工作，可以在合适的位置让出主线程，让浏览器有机会先处理用户输入；但这不是替代优化的办法，任务总量仍然需要控制。

一份可执行的排查清单

遇到“布局正常但点不动”时，可以按下面的顺序记录结果：

• 点击延迟是否能在性能录制中稳定复现？
• 卡顿发生前后是否存在超过 50 毫秒的主线程任务？
• 长任务来自页面初始化、事件回调，还是菜单状态更新？
• 调用栈中是否有第三方脚本、插件脚本或页面构建器生成的代码？
• JavaScript 是否在解析、编译或执行阶段占用了主线程？
• 事件回调是否遍历了过大的 DOM 或数据集合？
• 是否交替读取布局属性并修改样式，造成重复布局计算？
• 一次局部交互是否触发了大范围组件重新渲染？
• 拆分任务、缩小 DOM 更新范围或延后非关键工作后，交互是否恢复？
• 实验室中的 TBT 改善后，是否还需要用真实用户的 INP 数据复核？

最后一项很重要。TBT 适合帮助你找到“哪里堵住了主线程”，但它不能单独描述所有真实用户的交互体验。修复后，仍应在目标设备和实际页面流程中测试按钮、菜单、筛选器等核心操作，确认用户输入确实能更快得到视觉反馈。

对响应式 WordPress 页面来说，最有效的排查路径通常不是先换主题、换框架或删除一批插件，而是先用时间线确认长任务，再沿着调用栈检查事件监听、布局计算和更新范围。只要能把“点不动”对应到一个具体的主线程任务，后续优化就会从猜测变成有依据的修改。