Vercel 发布了 Next.js 16.3，将 Turbopack 和 Partial Prerendering 从实验阶段移至生产就绪模式。此次升级承诺，对于中型应用，构建速度将提升两到五倍，且页面加载速度能将可交互时间 (Time to Interactive) 缩短 40-60% —— 对于任何竞相交付功能的团队来说，这种提升都非常显著。
为什么这次变化至关重要
Next.js 长期以来在开发和生产构建中都依赖 Webpack（一个用 JavaScript 编写的 JavaScript 打包器）。在过去的一年里，Vercel 团队不断完善 Turbopack，这是一个基于 Rust 的替代方案，能够降低内存占用并加快构建速度。与此同时，他们测试了 Partial Prerendering (PPR)，作为一种将静态 HTML 与即时动态内容相结合的方式，但此前开发者必须将其视为“实验性选项”。通过将两者都提升为稳定版，Vercel 为生产团队提供了一个现成的性能升级方案，无需经历以往的试错过程。
Turbopack 进入稳定版
- 速度： 中型代码库的生产构建速度现在提升了两到五倍。
- 内存： 它降低了大型代码库的内存压力。
- 启用方式： 在
next.config.js中添加turbo: true即可完成设置。
代价是环境要求变得更加严格。Turbopack 要求 Node 18.17 或更高版本，并且项目所依赖的任何自定义 Webpack 插件都无法在 Turbopack 下运行。拥有大量插件流水线的团队在启用该功能之前，必须对这些扩展进行审计或重写。
Server Actions 的体验更加顺滑
Server Actions —— 即在服务器上运行但从客户端调用的函数 —— 现在拥有更紧密的 TypeScript 集成。编译器会自动推断类型，因此开发者可以不再手动编写类型注解。它还能端到端地理解嵌套对象和 Zod schema，从而减少运行时类型不匹配的问题。新的文件系统约定使 Action 的解析变得明确，有助于开发者避免因导入歧义而导致的细微 Bug。
Partial Prerendering (PPR) 已达到生产就绪标准
PPR 允许单个页面为永不改变的部分提供静态 HTML，同时单独对动态部分进行注水 (hydrating)。静态标记会立即渲染；随后，后台获取 (background fetch) 会让交互部分实现交互功能。这种方法将可交互时间 (TTI) 提升了 40-60%。
实现 PPR 非常简单：使用现有的静态生成 API 标记静态部分，并让动态部分回退到客户端渲染。由于静态 HTML 是作为一个完整的文档交付的，浏览器可以在任何 JavaScript 运行之前就开始渲染，从而提升了在慢速网络下的感知性能。
其他值得注意的改进
- 图像优化： 现在可以在 LCP (Largest Contentful Paint) 图像上设置
fetchPriority，确保浏览器优先获取英雄图 (hero image)。 - 字体处理：
next/font会自动对字符进行子集化处理，无需额外配置即可减小有效载荷大小。 - Middleware： 匹配引擎已使用 Rust 重写，从而提供更快的路由检查。Middleware 还可以返回完整的 HTML 响应，为边缘渲染页面 (edge-rendered pages) 开启了大门。
团队应采取的即时步骤
- 在开发环境中开启 Turbopack；一旦设置了
turbo标志，它在生产环境中的工作方式也是一样的。 - 升级 Node 到 20 或更高版本。
- 审查 Server Actions 以利用类型推断带来的好处；移除任何现在已变得多余的手动注解。
- 在单个高流量路由上试点 Partial Prerendering，在全站推广之前衡量 TTI 的改进情况。
注意事项与潜在问题
性能提升取决于是否满足新的运行时要求。如果项目仍停留在旧版本的 Node 上，或者过度依赖自定义 Webpack 插件，将会遇到阻碍。
总结： Next.js 16.3 为开发者提供了一个生产级的、由 Rust 驱动的打包器，以及一种融合静态与动态内容的成熟方法。现在就采用新的默认设置，修复兼容性差距，你就会看到构建速度更快，且终端用户的页面体验变得明显更加流畅。