Next.js 16 App Router: What Changed and Why It Matters

Next.js 16 Is Not a Minor Update

Every few years, Next.js ships a release that changes how developers build. Version 13 introduced the App Router. Version 14 stabilized Server Actions. Version 15 made async params mandatory. Version 16 brings Turbopack to default and finalizes the caching model.

Get the Velat Next.js 16 theme — $49 → https://creativitaz.gumroad.com/l/velat-next-js-ai-landing-page-themes-template

If you're building a new project today, Next.js 16 is the version to use. If you're upgrading from 15, there are a few things you need to know.

This article covers the changes that matter most for production sites — especially landing pages and content-driven sites like the ones Velat is built for.

Turbopack Is Now Default

For years, Turbopack was experimental. You had to opt in with a flag. In Next.js 16, it's the default bundler for both development and production builds.

The impact is real. Cold starts are faster. Hot reload is faster. Production builds compile in a fraction of the time.

In our own testing, building Velat with Turbopack takes about five seconds. The same build on Webpack takes closer to thirty. Over a full day of development, that difference adds up.

The migration is mostly automatic. If you had a custom Webpack config, you may need to port it to Turbopack's config format. For most projects, nothing changes.

Async Params Are Now the Norm

Next.js 15 made route params async. Next.js 16 enforces it more strictly.

In the App Router, dynamic routes like /blog/[slug] receive their params as a Promise. You have to await them before using them.

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const post = getPostBySlug(slug);
  return <Article post={post} />;
}

This change was made to support streaming and partial prerendering. It's a small change in practice, but it catches developers who copy old code from tutorials.

If you're upgrading, run the official codemod. It converts most cases automatically.

The Caching Model Is Finalized

Next.js has gone through several caching models. Version 16 settles on a simpler one.

The default behavior is now:

―Static by default — pages are pre-rendered at build time unless they opt out
―Dynamic on demand — use dynamic = "force-dynamic" to opt into per-request rendering
―Revalidation — use revalidate to set a time-based cache lifetime
―Tag-based invalidation — use revalidateTag to invalidate specific data

The important change is that revalidateTag now requires a second argument — a cache profile. This prevents accidental global invalidation.

revalidateTag("posts", "max");

For most sites, the defaults work. Only sites with heavy dynamic content need to think about this.

Image Optimization Is Still Automatic

next/image continues to handle image optimization automatically. In Next.js 16, the default cache TTL for optimized images is now four hours instead of sixty seconds. This reduces the load on your image optimization service.

Remote images still need to be whitelisted in next.config.js:

images: {
  remotePatterns: [
    { protocol: "https", hostname: "images.unsplash.com", pathname: "/**" }
  ]
}

If you're using images from a CDN or a third-party service, add the domain to this list. Otherwise, Next.js will refuse to serve them.

Middleware Is Now Proxy

If you used middleware in Next.js 15, you'll need to rename the file. middleware.ts is now proxy.ts, and the exported function is named proxy instead of middleware.

The functionality is the same. The rename was made to clarify what the file actually does — it proxies requests, it doesn't run generic middleware logic.

For most projects, this is a simple find-and-replace.

What Was Removed

A few features were removed in Next.js 16:

―AMP support — deprecated for years, now gone
―`next lint` — use npx eslint . instead
―`serverRuntimeConfig` — use environment variables
―`experimental.turbo` — moved to top-level turbopack config

If your project uses any of these, migration is straightforward. None of them are used in the Velat theme.

What This Means for Landing Pages

For landing pages and content-driven sites, Next.js 16 is a clear win.

Turbopack makes development faster. Async params make routing more predictable. The finalized caching model means fewer surprises in production. Static generation is still the default, so most pages load instantly.

The tradeoff is that the framework is more opinionated. There's less room for custom bundler config. For most projects, this is fine — the defaults are good.

If you're choosing a framework for a new landing page today, Next.js 16 is the obvious choice. It's fast, well-documented, and has the largest ecosystem of any React framework.

Should You Upgrade?

If you're on Next.js 15 and your project works, there's no urgent need to upgrade. Version 15 is still supported.

If you're starting a new project, use 16. The improvements in build speed and developer experience are worth it.

If you're upgrading, run the codemod first, then test thoroughly. Most projects upgrade in an afternoon.

Conclusion

Next.js 16 is a mature release. It doesn't introduce radical new concepts — it finalizes the ones introduced in 13, 14, and 15.

For landing pages and content sites, this is a good thing. Stability matters more than novelty. The defaults are sensible, the tooling is fast, and the ecosystem is large.

If you're building an AI startup landing page, Next.js 16 with App Router is the stack to use. The Velat theme is built on it, and it's available now.