Next.js 16.3 Preview 发布：Instant Navigations 让服务端应用接近零延迟导航

Next.js 16.3 Preview 发布了。

这次更新的核心，不是又加了一个小 API，也不是普通性能优化。

它真正想解决的是 Next.js 用户抱怨了很久的问题：
页面跳转太慢。

尤其是在 server-driven app 里，用户点一个链接，页面往往要等一次完整网络请求回来，屏幕上才有变化。
这和 SPA 那种“点一下立刻有反馈”的体验相比，差距很明显。

Next.js 16.3 引入了一个新能力：
Instant Navigations。

它想把 SPA 那种轻快的跳转体验，带进服务端驱动应用里。
而且不要求你放弃 Next.js 原本的 server-centric 模型。

这次更新重点是什么？

Next.js 16.3 Preview 主要有几个核心变化：

• Instant Navigations：让服务端应用也能拥有接近 SPA 的即时跳转体验。  
• Smarter Prefetching：不再每个链接都发一次预取请求，而是每个 route 预取一个可复用 shell。  
• Better DX：新增 Navigation Inspector、Playwright 测试 helper、Instant Insights 面板。  
• 更深的 AI 集成：新增 agent skill，帮助项目迁移到 Cache Components。

简单说：
Next.js 这次不是只在优化框架内部。
它是在重新设计“用户点击链接之后，页面应该如何响应”。

Instant Navigations：点击后立刻有反馈

以前 Next.js 应用最常见的问题是：
导航看起来不像“瞬间发生”。  

在传统服务端流程里，用户点击一个链接后，页面要先等网络请求完成。
请求回来之前，屏幕可能没有任何明显变化。
这就会让人感觉卡。

Next.js 16.3 的 Instant Navigations，就是为了解决这个体验问题。
它提供了一套 opt-in 工具，让你可以选择每条 route 在用户点击后如何响应。  

主要有三种方式。

1. 用 <Suspense> 流式渲染

你可以让用户先看到一个 loading shell。
内容随后再 streaming 进来。

也就是说，点击之后不是干等。
用户立刻看到界面结构开始变化。

<Suspense fallback={<Loading />}>
  <ProductContent />
</Suspense>

这种方式适合动态内容。
用户先进入页面框架，数据慢慢补齐。

2. 用 'use cache' 复用缓存 UI

如果某些组件或数据可以缓存，就可以通过 'use cache' 让 Next.js 在请求之间复用之前的 UI。  

用户点击时，先看到已有缓存内容。
新内容再逐步更新。

'use cache'

export async function ProductHeader() {
  const product = await getProduct()
  return <h1>{product.name}</h1>
}

这类体验会非常接近 SPA。
因为它不是等服务器完整响应后才动，而是先把能复用的东西立即展示出来。

3. 用 instant = false 主动关闭

不是所有页面都适合即时跳转。
有些页面你就是想保持传统服务端行为。  

比如一篇博客文章，你不希望先显示 loading 状态，而是想等完整内容回来再展示。
这时可以显式关闭：

export const instant = false

这代表：
这个 route 不参与 Instant Navigation enforcement。
它继续走传统 server-bound 行为。

开启 Cache Components

要使用 Instant Navigations，先在配置里打开 cacheComponents。

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

这个 flag 也代表 Next.js 正在回到一种更简单的模式：
默认动态。
没有隐藏的隐式缓存。
你想缓存，就明确写出来。

未来大版本里，cacheComponents 会变成默认行为。

Instant Insights Panel：慢导航直接暴露出来

这次开发体验里，最有用的新东西之一，是 Instant Insights panel。

它会出现在 dev overlay 里，自动指出哪些 route 正在阻塞导航。  

更狠的是：
开发环境里，慢导航会被当成错误处理。
这意味着你不用等上线后才发现某个页面跳转体验很差。
开发阶段就能看到问题。

当检测到 blocking fetch 时，面板会直接指出：
哪个文件。
哪一行。
是什么阻塞了即时导航。

并且它会给你三个修复选项。
每个选项旁边还有一个 “Copy as prompt” 按钮，可以直接丢给 Claude Code、Cursor 或其他 agent。  

三个修复方向分别是：

• 用 <Suspense> 包住组件，让 loading fallback 立即展示。  
• 给组件或数据请求加 'use cache'。  
• 用 export const instant = false 让这个 route 退出即时导航检查。

这点很适合现在的 AI 编程工作流。
框架不仅告诉你错在哪里，还把修复任务整理成 agent 能理解的 prompt。

预取机制也重做了

以前 Next.js 的预取逻辑很容易让人困惑。  

页面里只要有链接进入 viewport，Next.js 就会给每个链接发一次 prefetch 请求。
比如一个聊天侧边栏里有 20 个会话链接。
以前可能就是 20 个网络请求。
一个链接一个。

你打开 Network tab，就会看到一堆预取请求飞出来。
很多开发者看到这里都会懵：
为什么只是滚动一下，就发了这么多请求？

新方式：Partial Prefetching

Next.js 16.3 改了思路。
它不再按“每个 link”预取，而是按“每个 route shell”预取。

也就是说：
它会为每个 route 预取一个可复用 shell。
一次。
然后在当前 session 里缓存起来。

比如侧边栏里有 20 个链接：

/chat/1
/chat/2
/chat/3
...
/chat/20

它们都属于：

/chat/[id]

以前可能是 20 次预取。
现在只需要预取一次 /chat/[id] 的 shell。

这有点像 SPA 里的 per-route code splitting。
先拿到这个 route 的壳。
具体数据，等真正进入时再补。

这个 shell 机制也会成为未来离线导航能力的基础。
之后 Next.js 可能会探索：当网络短暂断开时，已经预取过的 route 仍然可以导航。

开启 Partial Prefetching

配置如下：

// next.config.ts
const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

和 cacheComponents 一样，partialPrefetching 未来也会成为默认能力。

单个 Link 也能深度预取

有时你不只想预取 route shell。
比如聊天页面里，你希望聊天标题也能瞬间出现。  

这时可以给单个链接显式开启更深层预取：

<Link prefetch={true} href="/chat/123">
  Open Chat
</Link>

但 Next.js 不会粗暴地渲染完整 route。
它只会渲染到同步可用的内容，或者被 'use cache' 标记过的内容。

这解决了以前的 all-or-nothing 问题。
以前要么几乎不预取。
要么预取太多。
现在可以更细地控制。

默认情况下，per-link prefetch 只限于 build-time content。
如果你想扩展到 request-time cached content，可以加：

export const prefetch = 'allow-runtime';

Navigation Inspector：直接看 shell 里有什么

Next.js DevTools 新增了 Navigation Inspector。
它可以在每次导航时暂停在 shell 阶段。
你能直接看到这个 route 预取了什么。
点 Resume 后，导航才会继续完成，显示完整页面。

这对调试非常有帮助。
因为你终于能直观看到：
哪些部分是立即可用的。
哪些部分必须等网络。
哪些组件拖慢了导航。

注意一点：
真实 prefetch 只会在 production mode 下运行。
所以开发时要理解这个限制。

Playwright 测试 helper：防止即时导航退化

Next.js 16.3 还提供了一个 Playwright helper：

instant()

用来测试某个 route 是否真的可以即时响应。  

示例：

import { expect, test } from '@playwright/test';
import { instant } from '@next/playwright';

test('product title is available immediately', async ({ page }) => {
  await page.goto('/products/shoes');

  await instant(page, async () => {
    await page.click('a[href="/products/hats"]');
    await expect(page.locator('h1')).toContainText('Baseball Cap');
    await expect(page.getByText('Checking inventory...')).toBeVisible();
  });

  await expect(page.getByText('12 in stock')).toBeVisible();
});

instant() 里面的断言，会在不等待网络的情况下运行。
如果里面的内容需要一次 roundtrip 才能出现，测试就会失败。  

这对防止回归很重要。
你可以把“页面点击后必须立刻出现什么”写进测试里，而不是靠肉眼感觉。  

Next.js 团队也在探索把这类错误提前到 build time 暴露出来。
如果能做到，部署前就能发现 instant route 退化。

Agent Skill：让 AI 帮你迁移 Cache Components

在老项目里启用 cacheComponents，往往不是改一行配置这么简单。
你可能要检查很多 route。
判断哪里应该 stream。
哪里应该 cache。
哪里应该 block。

所以 Next.js 16.3 提供了一个专门的 agent skill。
它会帮助你迁移 Cache Components。  

包括：  

• 识别阻塞 route。  
• 判断应该 Stream、Cache 还是 Block。  
• 用 Instant Insights 验证结果。

使用方式也很直接。
把下面这段 prompt 丢给 Claude Code、Cursor 或你正在用的 agent：

Install this skill https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-adoption
and adopt Cache Components in this project using it

这个 skill 会直接从 Next.js canary 仓库安装。
它会给 agent 足够上下文，让它根据每个 route 的情况做判断，而不是瞎猜。

这也是现在框架发展很明显的趋势：
不只是提供 API。
还提供给 AI agent 使用的迁移能力。

真实效果：v0 已经用上了

Next.js 团队在这次发布前，已经把 Instant Navigations 用到了 v0 上。
他们逐个 route 使用 Instant Insights panel 优化。  

结果导航时间明显下降。  

从 5 月 19 日到 6 月初，数据变化大概是：  

• p90 从约 0.9 秒降到约 0.35 秒。  
• p75 从约 0.5 秒降到接近 0。  
• p50 从约 0.35 秒降到接近 0。

也就是说，对大多数用户来说，导航几乎已经接近瞬间完成。
团队还在继续优化 prefetching。
目标是让各个百分位的导航时间都继续靠近 0。

快速总结

如果你只想记配置和 API，看这部分就够了。

开启 Instant Navigations：

const nextConfig = {
  cacheComponents: true,
};

让 route 退出即时导航：

export const instant = false;

开启 Partial Prefetching：

const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

单个链接开启深度预取：

<Link prefetch={true} href="/chat/123">
  Open Chat
</Link>

允许 request-time cached content 参与预取：

export const prefetch = 'allow-runtime';

Playwright 即时导航断言：

import { instant } from '@next/playwright';

怎么开始用 Next.js 16.3？

现在可以安装 preview 版本：

npm install next@preview

但要注意：
这是 pre-production release。
Next.js 团队自己的应用已经在跑它，但你要不要直接部署给真实用户，还是得谨慎。
正式稳定版发布前，API 和行为都可能继续变化。

最后

Next.js 16.3 这次真正重要的地方，不只是“更快”。
而是它开始把 server-driven app 的导航体验，往 SPA 的即时反馈靠近。

以前你可能要在两者之间选：
要服务端模型。
还是要 SPA 体验。

现在 Next.js 想给你第三条路：
服务端继续负责数据和渲染。
客户端获得更快的点击反馈。

用户不再等一整个网络 roundtrip 才看到变化。
这就是 Instant Navigations 的价值。

如果它稳定下来，Next.js 应用里“点链接像卡了一下”的体验，可能会少很多。
想了解更多前端技术新动向？欢迎到 云栈社区 一起交流。