Next.js 16.3 and the upgrade I stopped deferring
Next.js 16.3 promises 90% less dev memory and 22% more SSR throughput. What those numbers mean if you're a major behind, and why August's CVEs set the date.
Next.js 16.3 shipped on August 3 with a claim I've wanted to be true for about two years: long next dev sessions now use up to 90% less RAM. Three weeks later, Vercel shipped an out-of-cycle security release with two critical remote-code-execution advisories. Those arrived as separate announcements, and I read them a week apart. They are the same decision.
This site runs 15.3.8. Writing this post is what made me look.
What 16.3 actually changes
Everything below is Vercel's own benchmark, measured on Vercel's own applications. I have not run any of it against this site, because this site is a major version behind and the comparison would be dishonest. I would rather hand you an attributed number than a borrowed one.
Dev memory. Turbopack now enables disk caching and memory eviction by default. Vercel reports the vercel.com dashboard dropping from 21.5 GB to 2 GB after compiling 50 routes, and nextjs.org from 4,600 MB to 840 MB. That is the "up to 90%" in the headline, and the shape of it matters more than the percentage: this is the long-session leak, not cold-start memory. If your dev server is fine for an hour and unusable by mid-afternoon, this is the fix.
Build caching. The same disk cache now applies to next build. Vercel's numbers range from 1.4× on vercel.com/home to 5.5× on vercel.com/geist. Repeat builds on CI benefit most, which means the gain depends on whether your CI preserves the cache between runs — the changelog can't tell you that, your pipeline can.
SSR throughput. The App Router rendering layer moved from web streams to native Node.js streams, removing a conversion in the hot path. Vercel measured up to 22% more requests under load with no application changes. This one is free in the truest sense: it isn't a flag, it isn't opt-in, and there's nothing to configure.
TypeScript 7 can now do type checking during next build, if you bump your local dependency. And import.meta.glob landed in Turbopack, which is directly relevant to any blog that reads MDX off the filesystem — including this one.
The larger story in 16.3 is Instant Navigations, an opt-in set of behaviors behind cacheComponents and partialPrefetching. Vercel has said these become default in a future major. That's the part I'd budget real time for, and it is not what upgrading is for today.
The upgrade tax the changelog doesn't price
15.3 to 16.3 is not a version bump, it is a migration. Turbopack's role changed, the caching model was deliberately simplified toward "dynamic by default, no hidden or implicit caching," and the 'use cache' primitive is now the thing everything else is being built on. None of that is a surprise if you've been following along; all of it is work if you haven't.
So the honest sequencing is two moves, not one:
- Take the patch on the line you're already on. Nothing to migrate, nothing to test beyond your existing build.
- Evaluate 16.3 on a branch, with a real build and a real load test, on your own schedule.
Collapsing those two into one decision is how a security patch ends up waiting three weeks behind a migration. The patch has no dependency on the migration. Ship it separately.
The security release removed the "later" option
On August 25 — moved forward a day from the originally announced date, after a second critical was identified — Vercel published 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS), covering two critical-severity issues:
- AVIF image optimization RCE (GHSA-2xp9-vwfh-vxw4). A flaw in libheif, reached through
sharp, can give unauthenticated remote code execution when Next.js optimizes an attacker-controlled AVIF image. The patched releases disable AVIF optimization outright until the upstream fix lands. - Windows-hosted RCE (CVE-2026-75604). Applications using both the Pages Router and the App Router without Cache Components, served from a Windows filesystem. Linux and macOS are unaffected, and there is no known workaround for the applications that are.
That's the qualifier I'd want someone to give me, rather than a blanket "you are vulnerable." Reachability is the whole question with this class of bug. But "probably not reachable" is a reason to stay calm while you patch, not a reason to skip patching — the exposure changes the day someone adds a remote image source and doesn't think about a CVE from last August.
What I'm doing
Patch first, on the line I'm already on. Then put 16.3 on a branch and actually measure it against this app, because that's a post I can write with my own numbers instead of Vercel's.
The performance work in 16.3 is a good reason to want the upgrade. It is not the reason to move this week. The two advisories are.
Sources: Next.js 16.3, August 2026 Security Release, Update: August Next.js Security Release