页面跳转慢，不一定是服务端真的慢。很多时候，数据已经可以提前获取，目标页面的共享布局也早已存在，但路由器仍要等到点击后才开始准备工作。Next.js 16.3 的 Instant Navigations 案例值得关注，正因为它把优化重点放在用户真正感知到的时刻：点击链接后，目标界面能否立刻出现。v0 团队还把测试与编码智能体引入改造过程，让性能优化从一次性调参变成可验证、可重复的工程工作。
“瞬时”不是让所有请求消失
导航性能通常包含几段不同的时间：识别用户意图、加载路由代码、获取服务端数据、生成 React Server Components 响应、提交新界面。只盯着接口耗时，容易漏掉点击之前本可完成的工作。
Instant Navigations 的核心可以理解为：尽可能提前准备可复用的路由结果，并在点击发生时优先展示已经就绪的内容。这里的目标不是承诺零网络请求，而是缩短 click-to-render，也就是从点击到用户看到有效反馈的时间。
对 v0 这类交互密集的产品尤其重要。用户会在项目、会话和生成结果之间频繁切换；即便每次只多等几百毫秒，连续操作也会明显拖慢节奏。
这类优化需要同时守住三个边界：
- 预取不能制造失控的带宽和服务端负载。
- 缓存结果必须遵守权限、租户和数据新鲜度约束。
- “立即出现”不能靠展示错误页面或长期停留在无意义的骨架屏来实现。
从链接预取到可观测的导航预算
Next.js 应用可以先从框架已有的链接预取能力入手。生产环境中，next/link 会为进入视口的链接准备相关资源；对高概率目标，还可以在用户表达意图时主动调用 router.prefetch()。
下面是一个可以直接改造的客户端组件。把 /projects/[id] 换成你的真实路由即可：
'use client';
import Link from 'next/link';
import { useRouter } from 'next/navigation';
type ProjectLinkProps = {
id: string;
name: string;
};
export function ProjectLink({ id, name }: ProjectLinkProps) {
const router = useRouter();
const href = `/projects/${id}`;
function prepareNavigation() {
router.prefetch(href);
}
return (
<Link
href={href}
prefetch
onPointerEnter={prepareNavigation}
onFocus={prepareNavigation}
>
{name}
</Link>
);
}
onPointerEnter 覆盖鼠标用户，onFocus 照顾键盘导航。不要给页面中数百个低概率链接全部加激进预取；应优先处理最近项目、当前会话的相邻结果、搜索建议等高意图入口。
仅有实现还不够。导航优化最容易出现“本机很快、线上退化”的情况，因此需要一条可自动执行的性能测试。下面的 Playwright 示例记录点击到目标标题可见的耗时，并设置明确预算。运行前安装 @playwright/test，同时把选择器与地址改成项目中的实际值：
import { expect, test } from '@playwright/test';
test('project navigation becomes visible within budget', async ({ page }) => {
await page.goto('http://localhost:3000/projects');
const target = page.getByRole('link', { name: 'Demo project' });
await target.hover();
await page.waitForTimeout(100); // 给意图预取一个短暂窗口
const startedAt = Date.now();
await target.click();
await expect(
page.getByRole('heading', { name: 'Demo project' })
).toBeVisible();
const navigationMs = Date.now() - startedAt;
expect(navigationMs).toBeLessThan(500);
});
对应的执行命令如下：
npm install --save-dev @playwright/test
npx playwright install chromium
npm run build
npm run start &
npx playwright test tests/navigation.spec.ts
500 毫秒只是示例预算，不是框架承诺。团队应在 CI 中使用稳定环境、多次采样和分位数统计，避免把一次偶然波动误判为回归。还应分别测试预取命中与冷导航，因为两者代表不同的真实场景。
测试给编码智能体一条清晰的跑道
编码智能体适合处理边界明确、反馈快速的任务。导航性能改造恰好可以被拆成这样的循环：测试复现慢导航，智能体定位路由、数据依赖和链接入口，提交小范围修改，再通过同一组功能与性能断言验证结果。
可以给智能体类似下面的任务说明：
目标：把 /projects 到 /projects/[id] 的热导航控制在 500ms 内。
约束：
- 不改变权限检查和数据新鲜度语义。
- 不对项目列表中的所有链接执行无条件预取。
- 保持浏览器前进/后退行为正确。
验证：
- 运行 tests/navigation.spec.ts。
- 运行现有路由与权限测试。
- 报告修改前后的多次测量结果。
这种任务描述比“让页面更快”有效得多。它给出了目标路由、性能预算、不可破坏的行为和验收命令。智能体可以加速搜索与重复修改，但不能替代架构判断：哪些数据允许缓存、预取是否会泄露租户信息、动态内容是否会陈旧，仍需要工程师明确。
别让视觉上的快掩盖数据问题
Instant Navigations 最危险的误用，是把“立即切换”简化成“立即显示任意东西”。如果目标页面先出现旧项目名称，随后跳成新名称，用户感知到的不是速度，而是不稳定。
实践中可以把内容分成三类：
- 共享且稳定的布局，例如导航栏、编辑器外壳和页面结构，可以优先复用。
- 可安全预取的数据，例如用户有权访问的项目摘要，可以按框架缓存策略提前准备。
- 强时效或敏感数据，例如额度、权限状态和刚生成的结果，需要重新验证或保留明确加载状态。
除了 click-to-render，还要观察预取请求量、缓存命中率、取消请求数量、服务端 CPU，以及错误页面是否被缓存。单一前端指标下降，却换来后端流量翻倍，并不是成功。
落地时按这份清单推进
先选一条高频导航路径，而不是同时改造整个应用。为它建立冷导航和热导航基线，再加入可重复的浏览器测试。随后只对高意图链接启用预取，确认权限与新鲜度语义没有变化，并在真实网络条件下测量尾延迟。
引入编码智能体时，把性能预算、行为约束和验证命令一起交给它；将修改保持在小范围内，便于审查每一次缓存或预取决策。最终上线应采用渐进发布，并同时观察客户端体验和服务端成本。
Instant Navigations 的价值不只是一项路由能力。更重要的是，它展示了一种可复制的方法：把“感觉更快”写成测试，把复杂优化拆成可验证的小步，再让自动化工具在明确边界内加速执行。