Next.js 页面跳转终于不卡了？Next.js 16.3 这个 Navigation Shell 我先跑了一遍

写过 Next.js App Router 的同学，多多少少都被两件事折磨过。

一是点了链接没反应，等服务器回包页面才切换的导航迟钝感。二是每次路由跳转都要等服务端把整个页面重新拉一遍，即使 header、sidebar 这些完全没变的部分也要跟着一起等。

这其实是 RSC（React Server Components）架构的一个”原罪”——服务端渲染虽好，但每次跳转都要走服务端这条路的体验代价，确实让人头疼。

Next.js 16.3 最近放出了一个预览版，针对这个痛点给出了一个新方案：Navigation Shell。

导航慢的根因在哪？

先说清楚为什么 RSC 时代导航会慢。

在传统 SPA 里，路由跳转靠的是浏览器自身的 History API，切页面本质上是”把旧的 DOM 换掉”，header 还在，浏览器自己就能判断哪些区域要更新，速度快，体验顺滑。

到了 RSC 时代，每次导航都会触发完整的服务端渲染——服务端不仅要重新拉数据、重新渲染，还要等流式传输完成，浏览器才能开始绘制新页面。这中间有一个不可省略的等待时间，用户感知到的就是”点了没反应”。

现有的 Prefetch 机制其实已经在解决这个问题——Next.js 会提前把路由数据预加载，但这个预加载是”按请求”来的，每个 <Link> 各自独立 prefetch，没有复用，没有共享。用的人多了，预加载本身也变成了带宽和计算的压力。

Navigation Shell 是什么？

Navigation Shell 的思路很简单：把页面拆成两部分——不变的壳（Shell）和变化的内容。

壳是什么？header、sidebar、底部导航这些跨路由共享的 UI 组件。只要这些不动，浏览器就不需要重新渲染它们，可以直接复用已有的 DOM 结构。

内容是什么？就是每个路由自己独有的部分——文章正文、商品列表、评论区域，这些才是每次需要重新拉取的。

具体怎么工作的？

点击链接时，Navigation Shell 会先渲染一个新的”壳”，把 header、sidebar 这些部分直接复用过来，然后在壳里异步加载新路由的内容。用户看到的页面几乎是瞬间切换的，不会有空白或等待的感觉。

预加载策略也改了。之前是”每个链接各自 prefetch”，现在变成”每个路由一个可复用的预加载缓存”。第一次访问某条路由时，Next.js 会把这个路由的完整内容缓存下来，后续再访问，直接从缓存里拿，速度更快。

这还不是全部——Vercel 同步放出了三个官方 Agent Skill，专门帮你把老项目迁移到这套新行为上：

• next-dev-loop 解决开发时的热更新问题
• next-cache-components-adoption 帮你识别哪些组件适合被缓存
• next-cache-components-optimizer 自动分析页面结构，告诉你哪些部分应该抽出来做 Shell

怎么用它？

目前 Navigation Shell 还是预览版功能，需要手动开启。官方建议先用 create-next-app 拉一个新项目测，体验稳定了再迁移老项目。

# 创建预览版项目
npx create-next-app@latest --version 16.3.0-canary.x

在 next.config.ts 里加上：

const nextConfig = {
  experimental: {
    ppr: true, // Partial Prerendering，Navigation Shell 的基础
    unstable_navigationShell: true,
  },
}

有没有代价？

有，但不算大。

SSR 的调试复杂度会增加。Navigation Shell 把”服务端渲染”这件事从”整页”拆到了”壳 + 内容”两层，错误追踪和日志都要跟着变。官方为此还专门升级了 DevTools，NavigationInspector 可以让你看到每个 Shell 的渲染路径。

不是所有项目都值得现在上。如果你的页面本来跳转就很快（数据量小、渲染简单），Navigation Shell 的收益有限。但如果是内容丰富、路由嵌套深、用户停留时间长的项目，这个改动带来的体验提升会非常明显。

向前兼容是有的。这是一套可选行为，不改你的现有代码，只是多了一个开启的开关。等它 stable 了再全量切也不迟。

我的判断

RSC 把”服务端渲染”这件事重新拉回了前端的主叙事，但代价是每次导航都要重新走一遍服务端。Navigation Shell 是在不放弃 RSC 优势的前提下，补上了 SPA 那边的体验短板。

这个思路本质上是：让服务端渲染只做它该做的事——拉取动态数据——而不是把整个页面都重新渲染一遍。

如果你的项目用 Next.js App Router，强烈建议开一个 preview 项目跑一遍，感受一下”点链接秒切”和”等服务端回包”的差异。2026 年的前端体验，用户的耐心真的没有以前那么足了。

下一步：用 create-next-app 起一个 16.3 canary 项目，把你现有的某个页面迁移过去，先跑通 Navigation Shell，再决定要不要上生产。