# Next.js 16: what changes for corporate websites

> What Next.js 16 brings and what it means for a corporate website: Turbopack, async APIs, proxy instead of middleware, caching and requirements to upgrade without surprises.

URL: https://codegea.com/en/nextjs-16-what-changes-for-corporate-websites
Node.js · 2026-10-02 · Derian Pinto

If your corporate site is built with Next.js, or was proposed to you in Next.js, it helps to know what changed in version 16 and whether it affects you. Most of the changes are for developers, but a few have a direct impact on maintenance, speed and the cost of upgrading. This guide translates it into business language without losing technical rigor. Our own site is built with Next.js 16, so we speak from having used it.

> For a corporate site, what matters about Next.js 16 is not a new feature: it is that it now demands more modern practices, and that upgrading late costs more than upgrading on time.

## Summary for decision-makers

| Change | What it means in practice |
| --- | --- |
| Turbopack by default | Faster builds and development; less waiting for the team |
| Async request APIs | Old code that reads parameters synchronously stops working and must be migrated |
| `middleware` is renamed `proxy` | A change of name and runtime; the file needs adjusting |
| Cache Components (optional) | A new way to decide what is cached, enabled through configuration |
| React 19.2 and the React compiler | A modern base; the compiler can be enabled as an improvement |
| Renewed navigation and prefetching | Lighter transitions with no code changes |
| Higher minimum requirements | Node.js 20.9 or later and TypeScript 5.1 or later |

## Turbopack by default

Next.js 16 uses **Turbopack** as the default compiler in both development and production. For you it means faster builds and reloads. If your project has custom Webpack configuration, it may need adjustments or keep using Webpack explicitly; it is worth checking before upgrading.

## Async request APIs

In earlier versions it was still possible to read certain request data (for example, `cookies`, `headers`, `draftMode`, and a page's `params` and `searchParams`) synchronously. In 16 that compatibility **is removed**: they must be read with `await`. A codemod automates much of the change, but the result always needs review.

For you: if your site comes from version 14 or earlier, this upgrade may be more work than expected. The longer you wait, the more changes pile up.

## `middleware` is now `proxy`

The file that intercepted requests (redirects, route rewrites, headers) is renamed `proxy` to make clear it operates at the network boundary. There is one detail: `proxy` runs in the Node.js runtime, not the "edge" runtime. On our site, for example, it holds the per-language route translation and the redirect of old URLs, which matters a lot for not losing rankings (we explain it in [how to migrate without losing Google rankings](/en/how-to-migrate-your-website-without-losing-google-rankings)).

## Caching: Cache Components

Next.js 16 introduces **Cache Components**, an explicit way to state which parts of a page are cached and which are computed on every visit. It is optional and enabled through configuration. For a corporate site, where almost all content changes little, this lets you combine nearly static pages with dynamic pieces without losing speed. In addition, the functions for revalidating content are refined (for example, `revalidateTag` now works with cache life profiles, and `updateTag` and `refresh` exist for specific cases).

For you: if your site uses a CMS, published changes must show up without delay. That revalidation logic is what needs careful migration.

## React 19.2 and the React compiler

Version 16 uses React 19.2 and brings stable support for the **React compiler**, which optimizes rendering automatically. It is not mandatory and its effect depends on each application; on a corporate site with little interactivity, the benefit is usually modest.

## Lighter navigation

Page prefetching was redesigned: shared layouts are no longer downloaded several times and only what is missing is prefetched. It needs no code changes and improves how fluid moving between pages feels.

## Minimum requirements

- **Node.js 20.9 or later** (Node 18 is no longer supported).
- **TypeScript 5.1 or later.**
- Recent browsers: Chrome, Edge and Firefox 111+, Safari 16.4+.

If your server or deployment process uses an old Node version, it must be upgraded first.

## Should I upgrade?

It depends on where you are:

- **New site:** start straight on 16.
- **Site on 15:** the migration is manageable, with the codemod and testing.
- **Site on 13 or 14 (or on the Pages Router):** plan the upgrade in stages; the jump accumulates several changes.
- **A site that works and rarely changes:** upgrade in a planned window, not out of urgency. But do not leave it for years: old dependencies stop receiving security fixes.

## How to upgrade without surprises

1. **Back up** and work on a branch or test environment.
2. **Check the requirements** (Node, TypeScript, dependencies).
3. **Run the codemod** and review the changes.
4. **Migrate** `middleware` to `proxy` and the async APIs.
5. **Test** routes, redirects, forms, CMS preview and speed ([Core Web Vitals](/en/core-web-vitals-in-2026-what-they-are-and-how-to-improve-them)).
6. **Deploy** at a quiet time and monitor.

## How we see it at Codegea

Keeping a site up to date is part of looking after it, and a [retainer plan](/en/retainer) covers it. If you are choosing technology for your corporate site, read [headless WordPress vs Payload CMS](/en/headless-wordpress-vs-payload-cms-for-marketing-sites) and see our [corporate websites](/en/services/corporate-website-development) service. For a review of your current site, write to us from [contact](/en/contact).