- Vercel reworked v0 navigation with Next.js 16.4. Shared Runtime Cache spend rose 4.3× (about $3.44 a day); Vercel says whole-app daily cost was 2.9% lower, though traffic also changed.
- For these v0 pages, the experience before a click became a test that runs on every change, with its cost tracked.
- Ask your team what users must see before a click, and who reviews the line between shared and private cached data.
Most people have clicked a page they opened yesterday and watched loading placeholders appear again. That wait is a decision about where work happens: before the click, after it, or twice. The lesson from Vercel's v0 is that this decision can now be written down, tested and priced.
What Vercel changed in v0
Vercel's Next.js team published an account on October 16 of how it reworked navigation in v0, its AI app builder. Outside the main chat screen, people met loading skeletons when they returned to pages they had already visited. Content was also not always ready before the first click.
Vercel wanted the feel of a single-page app: content fetched on the way in and still there on the way back.
Next.js 16.3 introduced Partial Prefetching. Release 16.4 gave developers finer say over when cached content loads. It also shipped a Skill, next-partial-prefetching-optimizer, to tune what gets prefetched. A Skill is a packaged set of instructions for a coding agent. Projects created with create-next-app now start with Cache Components and Partial Prefetching switched on.
How it works
Before, prefetch={true} fetched the whole destination, dynamic content included. That could load pages nobody opened, and an early click was still slow. Turning prefetching off moved all the work to after the click.
Partial Prefetching splits the job. The reusable parts of a page load before the click. The rest loads during navigation. Cached content can be reused when the user comes back.
The team made this testable with instant(), a Playwright test helper. It holds back anything that arrives only during navigation. A test can then assert what must already be on screen before the click. The Skill guides an agent through a loop until that test passes. Once written, the test lives in the repository, so a continuous-integration run can flag any later slip.
Where the data is cached matters. Public template data went into 'use cache: remote'. On Vercel, that is a Runtime Cache shared across users. Personalized settings pages used 'use cache: private', which keeps content in the browser. The account or team was part of the cache key, so each one's content stayed separate.
Vercel notes that a self-hosted next start keeps 'use cache: remote' in memory unless you configure cacheHandlers.remote.
Speed has a price, and the team measured it
Vercel's first pass also kicked off the richer prefetch for each card in view on the templates page. Prefetch requests to /templates/[id] rose 2.9×. The team changed it to wait for hover, focus or touch.
Once every pull request had landed, the shared cache bill was 4.3× what it had been before the refactor. That is roughly $3.44 more a day. Vercel says reduced request volume, compute and data transfer outweighed the increase. It reports total daily cost 2.9% lower. Request-serving costs the team tracked fell 14.4%.
Vercel adds a caveat. Traffic and unrelated deployments changed in the same period. It treats the figures as confirmation that the work did not make v0 more expensive, not as savings caused by this work alone.
The idea behind the numbers
Think of a kitchen that preps ingredients before the dinner rush. Prep costs money, and over-prepping wastes it. The v0 team did the equivalent. It decided what to prepare, when to prepare it, and what could wait until the order arrived.
This shows a shift in how speed is managed. The experience before a click became a test that fails when broken. The cost of that experience became a metric reviewed after each change. Vercel says it tried each change in preview and tracked four production metrics after release. It also doubled its instant() tests across the affected navigations.
The line between shared and private cached data deserves the closest review. On the template pages, the agent split what any visitor may see from what belongs to the logged-in viewer. That line decides what is shared across users and what stays with one person. An agent can propose it quickly. A person should still own it.
Questions for your team
Ask which pages customers return to most, and what they must see before they click. Ask whether that is written as a test that runs in CI. Ask who reviews the boundary between shared and per-user cached content when an agent changes it.
Ask for the cost baseline before the change and the same metrics after it. Include request volume and cache spend, not only page speed. If you self-host, ask where the remote cache lives.
For these v0 pages, the experience before a click is now a test that runs on every change, with its cost tracked.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Next.js (Vercel).
