# Next.js 16 for marketing websites

> What Next.js 16 changes for a Next.js marketing website: Cache Components, Turbopack by default, proxy.ts, and what to plan before you upgrade or start fresh.

Canonical page: https://kyvrel.com/blog/nextjs-marketing-website
Published: 2026-04-07 · 5 min read · Kyvrel

Next.js 16, released in October 2025, makes a Next.js marketing website simpler to keep fast. Caching is now explicit, Turbopack is the default bundler, and middleware became `proxy.ts`. For most marketing sites, the practical result is static pages with small live parts, quicker builds and fewer caching surprises. Here is what changed and what it means for the people who run the site.

We build marketing sites on Next.js, so this is written from the build side. We focus on the changes that affect content teams, performance and budgets, not on every line of the changelog.

## What Next.js 16 changes for a Next.js marketing website

The [Next.js 16 release notes](https://nextjs.org/blog/next-16) list many changes. Five matter most for marketing sites:

1. **Cache Components.** A new model where you mark what can be cached, with the `"use cache"` directive. Everything else is dynamic.
2. **Turbopack by default.** The Rust-based bundler is now the default for new projects, in development and production builds.
3. **`proxy.ts` replaces `middleware.ts`.** The request layer gets a clearer name and runs on the Node.js runtime.
4. **Clearer cache invalidation.** `revalidateTag` takes a cache profile, and a new `updateTag` covers read-your-writes cases in Server Actions.
5. **React 19.2.** View Transitions and the `Activity` component come with the new React release.

There are also breaking changes: Node.js 20.9 is the minimum, synchronous access to `params` and `cookies` is gone, and the `next lint` command was removed.

![Flow diagram of a page request where a cached static shell is served first and a small dynamic section streams in after](https://kyvrel.com/blog/inline/nextjs-marketing-website-1.png)

## Cache Components: static pages with live parts

Earlier versions of the App Router cached a lot implicitly. Teams often found a page stale, or dynamic when they expected it static, and had to read the docs closely to find out why. Next.js 16 flips this. With `cacheComponents` turned on, you decide what is cached, at the function or component level.

For a marketing site, the pattern is straightforward. Content from the CMS is cached and tagged. When an editor publishes, a webhook invalidates the tag.

```ts
import { cacheLife, cacheTag } from "next/cache";

export async function getPricingPlans() {
  "use cache";
  cacheLife("hours");
  cacheTag("pricing");
  const res = await fetch("https://cms.example.com/api/plans");
  return res.json();
}
```

A route handler that receives the CMS webhook calls `revalidateTag("pricing", "max")`, and the next visitor gets the new content. Request-specific pieces, such as a region notice or a signed-in state, sit behind a `Suspense` boundary and stream in after the static shell.

Why this matters to the business: the page shell can be served from the edge in milliseconds, while editors still see their changes go live without a full rebuild. That is good for Largest Contentful Paint, which we covered in [Core Web Vitals for marketing sites](https://kyvrel.com/blog/core-web-vitals-marketing-sites).

## Turbopack by default, and why editors notice

Turbopack was already stable for development in Next.js 15. In 16 it is the default for production builds too. The Next.js team reports 2-5x faster production builds and up to 10x faster Fast Refresh.

Build speed sounds like a developer concern. On a content-heavy site, it reaches the marketing team as well. Faster builds mean faster preview deployments, quicker fixes on launch day and lower CI costs. If a webhook still triggers a full rebuild for some pages, the wait gets shorter.

Projects with custom webpack configuration can keep webpack for now with a flag. We treat that as a temporary step and plan the move during the upgrade.

## proxy.ts and the other renames

`middleware.ts` is deprecated in favor of `proxy.ts`. The function inside is renamed from `middleware` to `proxy`. The behavior is close to what you know: redirects, rewrites, locale detection and header changes before a request reaches a page.

```ts
import { NextResponse, type NextRequest } from "next/server";

export function proxy(request: NextRequest) {
  if (request.nextUrl.pathname === "/old-pricing") {
    return NextResponse.redirect(new URL("/pricing", request.url), 308);
  }
  return NextResponse.next();
}
```

The new name is more honest about what this layer does. It is a good moment to review what your middleware actually runs on each request, since every millisecond there sits in front of every page view.

Other changes worth a line in your upgrade plan:

- **Images.** `next/image` defaults changed, including a longer minimum cache time and a narrower default quality list. Check any custom image settings.
- **Routing.** Layout deduplication and incremental prefetching reduce how much data a page fetches when visitors hover over many links. Large navigation menus benefit most.
- **React Compiler.** Support is stable but opt-in. It reduces the need for manual memoization. Turn it on after the upgrade settles, not during it.

## Is Next.js 16 the right choice for your marketing site?

For many marketing sites, yes. Next.js fits when you want custom design without template limits, strong performance, several languages, and a headless CMS your team edits. It also fits when the marketing site shares components with a product built in React.

It is not the only good option. A small site that changes rarely may be fine on a hosted builder. A team with deep WordPress experience and many plugins may prefer to stay. Our comparison of WordPress and Next.js, linked at the end of this post, sets out the trade-offs side by side.

If you are moving from a visual builder, the migration path is the same as before, and our [Webflow to Next.js migration guide](https://kyvrel.com/blog/webflow-to-nextjs-migration) still applies. Version 16 makes the result easier to cache well.

![Timeline of an upgrade from Next.js 15 to 16: audit, codemods, caching review, testing and release](https://kyvrel.com/blog/inline/nextjs-marketing-website-2.png)

## Upgrading from Next.js 15: what to plan

For a typical marketing site on Next.js 15 with the App Router, the upgrade is a contained project. Our usual order:

1. **Check the runtime.** Node.js 20.9 or later in CI and hosting.
2. **Run the codemod.** `npx @next/codemod@canary upgrade latest` handles most renames and async API changes.
3. **Move middleware to proxy.** Rename the file and function, then test every redirect and locale rule.
4. **Review caching.** Decide which data is cached, set cache profiles and tags, and wire CMS webhooks to `revalidateTag`.
5. **Test images and routes.** Compare rendered images and check every page on a staging deployment.
6. **Measure.** Compare build time and Core Web Vitals before and after.

Sites still on the Pages Router, or on Next.js 13 or 14, need more time. We scope those after a short code audit, so the estimate is based on your code.

## Plan your Next.js marketing site

We build our [corporate website development](https://kyvrel.com/products/corporate-website) projects on Next.js. A corporate website starts at $8,500 for 8 page templates and typically takes 4-5 weeks. A headless CMS your team can edit and 2 revision rounds are included. A site with 10 templates comes to $9,400. The build covers static rendering and the caching setup described above.

If you are still choosing a platform, start with our [WordPress vs Next.js comparison](https://kyvrel.com/compare/wordpress-vs-nextjs). If you have chosen, send us your page list and languages, and we will reply within 4 business hours, Monday to Friday, Kyiv time.