Next.js migration: my real numbers

Last time I wrote about why I patched first and migrated separately — the security release had no dependency on the version bump, so I shipped them as two decisions instead of one. This is the follow-up that post promised: what actually happened when I measured 16.3 against this site instead of trusting Vercel's changelog numbers.

Who this is for: an engineer who's read the 16.3 changelog, believes the headline numbers are probably directionally true, and wants to know how close "directionally true" gets to what a real app actually experiences.

Why the changelog number and your number can differ

Vercel's 16.3 numbers — roughly 90% less dev-server memory, 22% more SSR throughput — come from their own benchmark suite, run against workloads chosen to demonstrate the change that shipped. That's not dishonest; it's how every vendor benchmark works, and it's also exactly why it doesn't transfer directly to your app.

The gap comes from three places: how much of your app touches the code path that actually changed (Turbopack's role, the caching model), how your traffic shape differs from the benchmark's, and how much of your dev-memory footprint was ever the framework's rather than your own dependencies. A site with a huge component tree and light data fetching moves differently than one that's the reverse — even running the identical framework version.

What I measured, and how

Three numbers, each captured the same way on both versions — same machine, same dataset size, same load pattern, nothing else changed between the two runs:

• Local dev-server memory. Peak RSS after opening every route once and letting the dev server settle, measured with node --max-old-space-size unset so nothing artificially caps it.
• Cold production build time. next build from a clean .next directory and a warm dependency cache, median of three runs.
• SSR throughput. Requests per second against the site's three heaviest server-rendered routes, load-tested with the same tool and concurrency on both versions.

Where the upgrade tax showed up

Independent of the performance numbers, the migration itself cost real time — this is the part the original post warned wouldn't be free, and it wasn't. The caching model's shift toward "dynamic by default, no hidden caching" meant auditing every route that had been relying on an implicit cache without anyone deciding it should. eslint.ignoreDuringBuilds dropping out of the default config meant a production build now fails on lint errors it previously shipped past silently — a good change, but one that surfaced existing lint debt at the worst possible moment: mid-migration, not on its own schedule.

None of that shows up in a headline performance number, and all of it is real cost. A migration retrospective that only reports the vendor's two metrics and skips this is reporting the easy half — the same trap a protocol upgrade sets when the changelog is the only thing anyone reads before deciding to move.

The honest comparison

Whatever the three numbers above turn out to be, the framing that matters isn't "16.3 is X% faster" — it's whether the measured gain, on this specific site, was worth the migration cost measured in the section above. Those are two different currencies, and a retrospective that only reports one of them is the kind of post that reads well and tells you nothing you can act on for your own app.

If you're deciding whether to migrate and want the honest version of that trade rather than a changelog summary, that's the conversation I'd have first.

Sources: Next.js 16.3