Next.js 16 for Business Websites and SaaS Products

Next.js 16 (opens in a new tab) was released on October 21, 2025. Since then it has had two minor releases: 16.1 (opens in a new tab) in December and 16.2 (opens in a new tab) in March 2026. That is enough time for the early rough edges to be fixed and for the upgrade path to be well documented.

If you are planning a new marketing site or SaaS product, or you run one on Next.js 15, this post covers what changed, what it means for performance and search, and what to check before you upgrade.

What changed in Next.js 16

Four changes matter most for teams shipping business software.

Turbopack by default

Vercel reports 2–5x faster production builds and up to 10x faster Fast Refresh with Turbopack. Those are the framework team's own figures, so treat them as a ceiling, but faster builds have a direct cost effect: shorter CI runs and quicker preview deployments for every pull request. Next.js 16.1 made Turbopack's file system cache stable and on by default for next dev, which cuts restart times on large projects. Next.js 16.2 reported about 87% faster next dev startup compared with 16.1.

Webpack is still available with the --webpack flag if a project depends on a custom webpack setup.

Cache Components and use cache

Earlier versions of the App Router cached a lot implicitly, which confused many teams. In Next.js 16, caching with Cache Components is opt-in. Dynamic code runs at request time by default, and you mark what should be cached with the use cache directive. The compiler generates the cache keys.

This also completes Partial Prerendering, which Next.js first introduced in 2023. A single page can serve a static shell immediately while personalized or live parts stream in. For a SaaS dashboard, the layout and navigation can be static while account data loads per request. For a marketing site, almost everything can be static, with a pricing widget or stock indicator fetched fresh.

It is enabled with cacheComponents: true in next.config.ts. New caching APIs came with it: updateTag() for read-your-writes updates in Server Actions, and a revalidateTag() that now takes a cache profile as its second argument.

proxy.ts

middleware.ts has been renamed to proxy.ts, and the exported function to proxy. The logic stays the same. The new file runs on the Node.js runtime only. The old middleware.ts still works for Edge runtime use cases, but it is deprecated and will be removed in a future version. The rename signals that this file is for lightweight request handling at the network boundary, such as redirects, header changes and auth cookie checks.

React Compiler

Built-in support for the React Compiler became stable after the compiler's 1.0 release. It memoizes components automatically, which removes a class of performance bugs where a whole screen re-renders on every keystroke. It is off by default, and the Next.js team warns that compile times will be higher because the compiler relies on Babel.

What this means for Core Web Vitals

Google's Core Web Vitals (opens in a new tab) set three targets, measured at the 75th percentile of real page loads: Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less.

Here is how the Next.js 16 line maps onto them.

LCP. Partial Prerendering through Cache Components lets the server send a cached shell straight away, so the main content can paint before slower data arrives. Next.js 16.2 also included a change to React that makes Server Components payload deserialization up to 350% faster, which the team says gives 25% to 60% faster rendering to HTML in real applications, depending on payload size. Faster server rendering shortens the time before the browser can start painting.

INP. The React Compiler can reduce wasted re-renders in interaction-heavy screens such as filters, forms and dashboards. It won't fix a page that ships too much JavaScript or runs heavy work on the main thread, so measure before and after you enable it.

Navigation. Next.js 16 rewrote prefetching. Shared layouts are downloaded once instead of once per link, and only the parts of a page not already cached are prefetched. The team notes the trade-off: more individual requests, with a much smaller total transfer.

The framework sets a good baseline. In our view, it rarely decides whether a business site passes Core Web Vitals. Oversized hero images, web fonts loaded without a fallback, cookie banners and third-party tags do more damage, and none of them are fixed by upgrading. One practical change to know about: Next.js 16 removed the size and First Load JS figures from next build output because they were inaccurate with Server Components. The upgrade guide (opens in a new tab) recommends measuring with Lighthouse or field data instead, which is the better habit anyway.

What it means for SEO

Next.js has long been a sound choice for search because pages render to full HTML on the server. Version 16 keeps that, and Cache Components make it easier to keep marketing pages fully static, which gives crawlers fast, complete responses.

Because dynamic code now runs at request time unless you cache it, decide early which pages and data are cached. Make that decision per route, write it down, and check it in code review. A landing page that quietly became fully dynamic will still rank, but it will be slower and cost more to serve.

Two removals may affect older sites. AMP support is gone entirely, so any AMP pages need a plan. And next/image changed several defaults, including a longer minimum cache time (4 hours instead of 60 seconds) and a single default quality setting of 75.

Should you build a new marketing site on Next.js 16?

It is a strong choice if the site will connect to a CMS, needs some dynamic content, is built by a team that already works in React, or is likely to grow into a product with logged-in areas. You get static pages for speed, server rendering for search, and one codebase as the site grows.

For a five-page brochure site with no plans to grow, it may be more framework than you need. A simpler static site generator or a hosted website builder will be cheaper to maintain, and nobody will need to apply framework security patches.

Should you build a SaaS product on it?

For a React-based SaaS product, Next.js 16 is a mature option. Server Components keep data access on the server, Cache Components give you a clear model for mixing cached and live data, and Server Actions cover most form handling.

Hosting is worth thinking through early. Next.js 16.2 made the Adapters API stable, which lets deployment platforms customize the build process. That matters if you deploy anywhere other than Vercel. If you plan to self-host, confirm how your platform supports caching, image optimization and proxy.ts before you commit.

What to watch when upgrading from Next.js 15

The official codemod handles much of the mechanical work:

npx @next/codemod@canary upgrade latest

Then check these by hand:

• Runtime versions. Node.js 20.9 or later and TypeScript 5.1 or later are required. Supported browsers start at Chrome 111, Edge 111, Firefox 111 and Safari 16.4.
• Async request APIs. params, searchParams, cookies(), headers() and draftMode() must be awaited. Synchronous access has been removed.
• Custom webpack config. If your project or a plugin defines one, next build fails under Turbopack. You can migrate it, ignore it with --turbopack, or keep webpack with --webpack.
• Middleware. Rename middleware.ts to proxy.ts. If you depend on the Edge runtime, note that proxy.ts does not support it.
• Linting. The next lint command is removed and next build no longer lints. Make sure ESLint or Biome runs in CI.
• Cache invalidation. Calls to revalidateTag() with one argument are deprecated. Add a cache profile such as 'max', or switch to updateTag() inside Server Actions.
• Parallel routes. Every slot now needs an explicit default.js file, or the build fails.
• Images. Review the new next/image defaults. Local images with query strings now need images.localPatterns.

Plan for security patches

On December 3, 2025, the Next.js team published a critical advisory (CVE-2025-66478) (opens in a new tab) for a vulnerability in the React Server Components protocol, tracked upstream in React as CVE-2025-55182. It was rated CVSS 10.0, could allow remote code execution, and affected App Router applications on Next.js 15.x and 16.x. The fix for the 16.0 line was 16.0.7, and the team advised anyone who had been online and unpatched as of December 4 to rotate their secrets.

The lesson for any business running Next.js is operational. Someone must own dependency updates, watch the framework's security advisories, and be able to ship a patch release within a day. Put that in your support agreement before launch.

Choosing Next.js 16 with your eyes open

Next.js 16 gives business sites and SaaS products faster builds, a clearer caching model and better server rendering performance. The gains depend on the decisions you make with it: what you cache, what JavaScript you ship, and how quickly you patch.

Planning a new site or product, or an upgrade from Next.js 15? Book a free 30-min call (opens in a new tab) and we can review the options with you.

Related service: Custom Software Development