NextJS如何优化Google Pagespeed的Total Blocking Time指标

AI 小北

2026-8-28

NextJS 站点 Total Blocking Time（总阻塞时间）针对性优化方案

你已经完成动态导入、移除无用JS、对齐官方基础最佳实践的前提下，剩余的TBT问题基本都是主线程长任务（单任务执行时长超过50ms）未清理干净导致的，按落地优先级从高到低尝试以下方案，基本可以把TBT压到合格线内：

1. 优先清理第三方脚本阻塞

绝大多数NextJS站点TBT超标，核心原因都是第三方脚本加载策略配置错误：

所有非首屏强依赖的第三方脚本（统计、客服插件、广告、非核心SDK），全部用NextJS内置的next/script组件加载，强制指定strategy="lazyOnload"，不要用默认加载策略，首屏只保留完全不能延迟的核心逻辑。
检查所有首屏引入的依赖包，杜绝全量引入UI库、工具库：比如不要整包引入AntD、Lodash这类大型库，换成按需导入写法，配合构建插件做自动按需打包，避免把几百KB根本用不到的代码塞到首屏，占用主线程解析执行时间。
如果你在用前端运行时加载的外部字体，直接换成NextJS内置的next/font做构建期字体优化，砍掉前端运行时的字体拉取、解析、DOM替换逻辑，这部分通常能消掉100-300ms的阻塞时长。

首屏Hydration是NextJS最常见的长任务来源，在你现有动态导入的基础上补充几个操作：

所有首屏不可见的组件（页脚、折叠评论区、弹窗、抽屉），动态导入时加上suspense边界，同时设置ssr: false，直接延迟到浏览器空闲时再加载执行，不要占用首屏主线程资源，示例写法：
```
import dynamic from 'next/dynamic'
const CommentArea = dynamic(() => import('@/components/CommentArea'), {
  ssr: false,
  suspense: true
})
```
纯展示、无任何交互逻辑的静态组件，直接标记为服务端组件（NextJS 13+ App Router）或者加server-only标记，不要注入客户端Hydration代码，从根源减少首屏要执行的JS量。
如果你用的是Pages Router，不要在自定义_app.js里嵌套多层全局Provider，只给真正需要全局状态的子组件包裹Provider，避免全页面Hydration时执行一堆无用的状态初始化逻辑。

清理完上面两块内容如果还有超过50ms的长任务，就手动拆分任务给主线程腾空间：

首屏不需要立刻执行的逻辑（埋点初始化、非核心数据预取、日志上报），全部放到requestIdleCallback或者setTimeout(..., 0)里延后到浏览器空闲时执行，不要挤在首屏加载的主线程队列里。
首屏组件的useEffect里不要写大段同步计算逻辑，比如大列表排序、大批量数据格式化，要么挪到服务端渲染阶段直接算好返回HTML，要么用Web Worker丢到后台线程计算，绝对不要占用主线程。
如果你用CSS-in-JS方案（比如styled-components、emotion），一定要开启服务端样式提取，不要让客户端在运行时做大量样式插入、选择器计算，这部分很容易产生连续几百毫秒的长任务。

确认next.config.js里swcMinify是开启状态，NextJS 12+默认开启，老版本手动打开即可，SWC压缩出来的代码执行效率比Terser高不少，能减少JS解析执行的耗时。
构建时确认NODE_ENV为production，开发模式的React带了大量警告、校验逻辑，执行速度比生产模式慢数倍，很容易导致TBT直接超标数倍。
跑一遍内置的包分析工具检查首屏依赖，重点盯单个体积超过20KB的首屏依赖，能换轻量替代就换，比如把moment换成dayjs，把全量lodash换成lodash-es按需引入，这类替换经常能直接降低几百毫秒的TBT。

排查小技巧：优化前打开Chrome DevTools的Performance面板，录一段首屏加载的性能轨迹，直接看主线程里占比最高的长任务是什么，对着最高占比的逻辑修改，比盲目调配置效率高很多。

内容的提问来源于stack exchange，提问作者GuiPab