A faster serving path for Next.js 16.3
The Next.js 16.3 release brings leaner prefetching, immutable static assets, and faster client-side navigation. Vercel has updated its platform to support the release, and early adopters upgrading from 16.2 report measurable gains: roughly 45% fewer prefetch requests on average (with some apps cutting more than 70%), 17% fewer CDN requests and 24% fewer bytes transferred for static content, and up to 60% lower global TTFB for frequently deployed projects.
CDN changes for immutable assets
Vercel now supports reusing immutable static assets across deployments for Next.js. These assets cannot suffer from version skew, even without Skew Protection enabled, and browser caches survive redeploys. Next.js 16.3 outputs these content-addressed files under the public path /_next/static/immutable/*, and the Vercel CDN uses that prefix to tell immutable assets apart from other static content. Because Next.js previously relied on query-parameter-based Skew Protection, the change also trims CDN traffic: 17% fewer requests and 24% fewer bytes for static files. Deployments finish up to 30% faster on average, since unchanged assets are not re-uploaded.
Framework authors who want similar behavior in their own toolchains can implement the immutable static files conventions described in the Build Output API docs.
Route metadata at scale
Next.js 16 introduced an optimization where shared application segments are prefetched once and reused across navigations, rather than fetched per link. Making that work requires each shared segment to be fetchable independently, which means frameworks generate far more paths for the same application. Every path gets a metadata file describing how to serve it — such as its prerender configuration — and the Vercel CDN reads that metadata on the path of each request. Globally that adds up to roughly 5 million lookups per second, so the cache needs to stay fast and hot.
As Next.js 16 applications shipped more paths, the cache accumulated more entries, hit rates fell, and p99 TTFB climbed for larger sites. Vercel reworked the route metadata layer in response. Instead of each segment's metadata occupying its own cache entry, entries are now combined into JSONL-formatted shards, with in-process and remote caching optimized around those shards. Fewer, larger entries yield better hit rates, while the JSONL format still allows fast lookups inside a shard. The result: roughly 2x faster route metadata serving with about 10x fewer cache misses.
This is a platform-level change already live for every deployment. Any framework that deploys through the Build Output API benefits automatically.
Observability for prefetching, ISR, and PPR
Vercel Observability and Runtime Logs can now show whether a request was a prefetch, and the query builder in Observability Plus exposes the same field. That matters because Next.js 16.3's prefetch improvements are what drive the 45% average reduction in prefetch requests.
ISR visibility is also getting a refresh. The ISR observability page now emphasizes time-based and on-demand revalidations, and exposes cache reasons and ISR write utilization. Vercel also published a guide on reducing ISR revalidation costs.
New today is observability for Partial Prerendering (PPR). PPR serves static page shells immediately and streams dynamic content like personalization or experimentation. It combines ISR and Vercel Functions into one system; Next.js 16 applications using Cache Components get PPR automatically when deployed to Vercel. The dashboard's PPR Observability page breaks down which requests served static content, dynamic content, or both — useful for confirming static shells work, catching routes that fell back to fully dynamic, and seeing when functions run. Drilldowns into ISR or Functions observability pages offer detail on cache revalidations or function executions.
Upgrade path
Next.js 16.3 is available now. Upgrade with pnpm add [email protected]. Full release notes are in the Next.js 16.3 announcement.
