Next.js 16 – Was ist neu und lohnt sich das Upgrade?

Warum dieses Release wichtig ist

Next.js 16 ist das bisher gründlichste Release seit Einführung des App Routers. Es ist kein Feature-Drop, sondern ein Aufräum-Release: Was in Version 15 noch als "experimentell" oder "temporär" markiert war, ist jetzt entweder stabil oder entfernt. Turbopack wird zum Standard-Bundler, Middleware heißt plötzlich Proxy, und das alte Partial Prerendering ist weg. Das klingt nach viel Arbeit – ist es auch, wenn man in einem gewachsenen Projekt steckt.

Für alle, die überlegen, ob sich das Upgrade lohnt: Die kurze Antwort lautet ja, spätestens wenn eure App sonst auf Node.js 18 oder React 18 festhängt. Die lange Antwort folgt jetzt.

Die wichtigsten Änderungen in Next.js 16

Die Release-Notes sind lang, aber in der Praxis entscheiden fünf Dinge über den Aufwand eures Upgrades: Turbopack als Default, verpflichtend asynchrone Request-APIs, die Umbenennung von Middleware, der neue Cache-Components-Ansatz und ein überarbeitetes Routing. Dazu kommen React 19.2 und die Stabilisierung des React Compilers.

1. Turbopack ist jetzt der Standard-Bundler

Bisher war Turbopack ein Opt-in über --turbopack. In Version 16 ist er der Default – sowohl für next dev als auch für next build. Das --turbopack-Flag in eurer package.json könnt ihr entfernen:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Die Konsequenz: Wenn euer Projekt eine custom webpack-Konfiguration hat, bricht der Build ab. Ihr habt drei Optionen:

• Komplett umsteigen: Webpack-Config auf Turbopack-Optionen migrieren (empfohlen).
• Turbopack erzwingen: next build --turbopack ignoriert die Webpack-Config.
• Webpack behalten: next build --webpack steigt explizit aus Turbopack aus.

Nebenbei ist auch die experimentelle Turbopack-Konfiguration aus dem experimental-Block gewandert. Statt experimental.turbopack heißt es jetzt nur noch turbopack direkt in der next.config.ts.

Neu ist außerdem das Filesystem-Caching für Turbopack im Dev-Modus. Das speichert Compiler-Artefakte auf der Platte und verkürzt Kaltstarts nach einem Server-Restart spürbar. Aktuell noch Beta, aber mit einem Flag aktivierbar:

const nextConfig: NextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};

2. Async Request APIs sind jetzt Pflicht

Das ist der Breaking Change, der die meisten bestehenden Projekte trifft. In Version 15 wurden cookies(), headers(), draftMode() sowie params und searchParams in Pages und Layouts bereits auf asynchronen Zugriff umgestellt – aber mit einer Übergangsfrist, die synchronen Zugriff noch erlaubte. Diese Frist ist vorbei.

Konkret bedeutet das: Überall, wo ihr bisher schreibt

export default function Page({ params }: { params: { slug: string } }) {
  return <h1>{params.slug}</h1>;
}

muss es jetzt so aussehen:

export default async function Page(props: PageProps<'/blog/[slug]'>) {
  const { slug } = await props.params;
  return <h1>{slug}</h1>;
}

Der PageProps-Helper wird von next typegen automatisch generiert (seit 15.5). Für die Migration selbst gibt es einen offiziellen Codemod, der den Großteil der Arbeit übernimmt:

npx @next/codemod@canary upgrade latest

Das betrifft übrigens auch opengraph-image.tsx, twitter-image.tsx, icon.tsx und apple-icon.tsx – die bekommen params und id jetzt ebenfalls als Promise. Wer dynamische OG-Images pro Slug generiert, muss hier anfassen.

3. Middleware heißt jetzt Proxy

Eine unscheinbare Umbenennung mit Haken. Aus middleware.ts wird proxy.ts, aus der exportierten middleware-Funktion wird proxy. Der Hintergrund: Next will klarstellen, dass diese Datei auf der Netzwerk-Ebene arbeitet, nicht als klassische Application-Middleware.

mv middleware.ts proxy.ts

export function proxy(request: Request) {
  // CSP-Header, Redirects, Auth-Gates
}

Wichtig: Die Edge Runtime wird in proxy nicht mehr unterstützt. Der Proxy läuft fest auf Node.js. Wer auf Edge-Features angewiesen ist, kann vorerst den alten middleware-Namen behalten – Next hat angekündigt, Edge-Runtime-Instruktionen in einer späteren Minor-Version nachzuliefern.

Für Projekte auf eigenem Hosting (z. B. VPS mit Coolify, wie unser eigener Stack) ändert sich praktisch nichts: Dort lief die Middleware ohnehin im Node-Runtime. Der Codemod benennt die Datei automatisch um.

4. Cache Components statt Partial Prerendering

Partial Prerendering (PPR) war in Version 15 eines der spannendsten experimentellen Features: statische Shell, dynamische Slots per Suspense, alles im selben Render-Pass. In Version 16 ist die experimentelle Flagge experimental_ppr ersatzlos weg. Stattdessen gibt es Cache Components:

const nextConfig = {
  cacheComponents: true,
};

Cache Components funktionieren anders als das alte PPR. Wer das Feature heute bereits produktiv nutzt, sollte in einer Next 15 Canary bleiben und die Migration separat angehen. Next stellt dafür einen eigenen DevTools-MCP-Befehl bereit, der die Umstellung automatisiert.

Parallel sind die Caching-Helfer aus dem unstable_-Stadium raus: cacheLife und cacheTag heißen nicht mehr unstable_cacheLife und unstable_cacheTag. Importe können direkt angepasst werden:

import { cacheLife, cacheTag } from 'next/cache';

Neu hinzugekommen sind außerdem updateTag und refresh. updateTag ist ein Server-Actions-exklusiver Helfer, der Read-your-writes-Semantik ermöglicht: Der User macht eine Änderung und sieht sie sofort, statt den alten Cache zu sehen. refresh triggert einen Router-Refresh direkt aus einer Server Action heraus – praktisch für Formular-Submits ohne manuelles Clientseitiges router.refresh().

Und: revalidateTag braucht jetzt zwingend einen zweiten Parameter (ein cacheLife-Profil). Die alte Ein-Argument-Form produziert einen TypeScript-Error.

// Alt
revalidateTag('posts');

// Neu
revalidateTag('posts', 'max');

5. Schnelleres Routing und Navigation

Das Navigation-System wurde komplett überarbeitet. Zwei konkrete Verbesserungen:

• Layout-Deduplication: Beim Prefetch mehrerer URLs mit geteiltem Layout wird das Layout nur einmal heruntergeladen.
• Incremental Prefetching: Next lädt nur die Teile nach, die noch nicht im Cache sind, statt die komplette Seite.

Beides erfordert keine Code-Änderungen. Der Effekt: niedrigere Transfer-Größen, dafür eventuell mehr einzelne Prefetch-Requests in den DevTools. Für Apps mit vielen verschachtelten Layouts (Dashboards, Newsroom-Listen, Produkt-Grids) ist das ein echter Gewinn.

6. React 19.2 und React Compiler stabil

Next.js 16 bringt React 19.2 in den App Router. Die drei Features, die euch im Alltag begegnen werden:

• View Transitions – native Animation beim Navigieren zwischen Routen, endlich ohne Framer-Motion-Gefrickel.
• useEffectEvent – trennt nicht-reaktive Logik sauber aus Effects heraus, ohne die Deps-Liste aufzublähen.
• Activity – hält UI im Hintergrund "lebendig" via display: none, ohne State zu verlieren. Gut für Tab-Wechsel und Wizard-Flows.

Parallel ist der React Compiler jetzt offiziell stabil (v1.0). Die reactCompiler-Option ist aus experimental ausgezogen und kann als Top-Level-Option gesetzt werden:

const nextConfig: NextConfig = {
  reactCompiler: true,
};

Der Compiler memoisiert Components automatisch und macht manuelles useMemo/useCallback-Tuning in vielen Fällen überflüssig. Eingeschaltet ist er per Default nicht – Next sammelt noch Build-Performance-Daten. Rechnet mit spürbar längeren Build-Zeiten, wenn ihr ihn aktiviert, da er auf Babel aufsetzt.

Was ihr vor dem Upgrade wissen müsst

Voraussetzungen

Next.js 16 erhöht die Mindestversionen deutlich:

Anforderung	Änderung
Node.js	mindestens 20.9.0 (LTS), Node 18 wird nicht mehr unterstützt
TypeScript	mindestens 5.1.0
Browser	Chrome/Edge/Firefox 111+, Safari 16.4+

Wer auf einem Managed-Hoster oder in einer Docker-Umgebung deployt, sollte die Node-Version prüfen, bevor das Upgrade in den CI-Lauf geht. Ein halb migriertes Projekt mit Node 18 ist der schnellste Weg in eine rote Pipeline.

Upgrade-Pfad in der Praxis

Next stellt mehrere Werkzeuge bereit, die den Großteil der mechanischen Arbeit übernehmen:

Option A – Codemod:

npx @next/codemod@canary upgrade latest

Der Codemod übernimmt:

• Turbopack-Konfiguration umziehen
• middleware → proxy umbenennen
• unstable_-Präfixe entfernen
• experimental_ppr aus Route-Segment-Config löschen
• next lint durch ESLint-CLI ersetzen

Option B – DevTools MCP: Wer mit AI-Agents wie Claude Code oder Cursor arbeitet, kann den offiziellen next-devtools-mcp einbinden und einfach prompten: "Next Devtools, help me upgrade my Next.js app to version 16". Der Agent läuft die Migrationspunkte dann strukturiert durch.

Option C – Manuell: Wer wenig Vertrauen in Codemods hat, installiert zuerst Next und React neu, fährt die Testsuite und arbeitet die Warnungen Schritt für Schritt ab:

npm install next@latest react@latest react-dom@latest
npm install -D @types/react@latest @types/react-dom@latest

In der Praxis ist eine Kombination sinnvoll: Codemod laufen lassen, dann manuell nachziehen, was der Agent nicht sauber übersetzt hat (erfahrungsgemäß komplexe async-params-Stellen in nested Dynamic Routes und OG-Image-Generatoren).

Lohnt sich das Upgrade?

Die ehrliche Antwort: Für neue Projekte ist die Frage längst entschieden – startet auf Version 16, fertig. Für bestehende Projekte hängt die Antwort vom Reifegrad ab:

Ja, zeitnah upgraden, wenn eines der folgenden Dinge auf euch zutrifft:

• Ihr nutzt Turbopack schon freiwillig und wollt den Build-Speed im CI haben.
• Ihr plant, den React Compiler einzusetzen.
• Ihr betreibt eine Next-App produktiv und wollt im Support-Fenster bleiben (Next 15 bekommt ab Release 16 nur noch kritische Sicherheits-Updates).
• Ihr seid noch auf Node 18 – dann ist das Upgrade ohnehin überfällig.

Ja, aber nach Feature-Freeze, wenn:

• Ihr Partial Prerendering produktiv nutzt (dort separate Cache-Components-Migration planen).
• Ihr eine stark individualisierte Webpack-Konfiguration mit Custom-Loadern habt.
• Ihr Edge-Runtime-Middleware mit Logik habt, die ihr nicht einfach auf Node portieren könnt.

Warten kann, wer gerade einen Produktionsstart oder Release-Freeze laufen hat. Dann lieber zwei Wochen danach sauber migrieren, statt den Launch zu gefährden.

Fazit

Next.js 16 ist kein glamouröses Release mit einem großen neuen Framework-Feature, sondern ein konsequentes Einlösen von Versprechen: Turbopack wird ernst, Async-APIs werden zur Norm, PPR wird in Cache Components überführt, der React Compiler ist produktionsreif. Das Ergebnis ist schnelleres Entwickeln, schnelleres Bauen, schnelleres Navigieren – und eine aufgeräumtere Codebasis.

Der Aufwand für das Upgrade ist überschaubar, wenn ihr den Codemod nutzt und euch eine Stunde für die Nachbesserungen nehmt. Die Performance-Gewinne im Dev-Server spürt ihr schon in den ersten Minuten. Allein dafür lohnt sich das Update.

Wer beim Upgrade einer größeren Produktivanwendung Unterstützung braucht – von der Evaluation über die Migration bis zum Rollout – für so etwas sind wir da. Schreib uns einfach, wir schauen uns euer Setup an und sagen klar, was sinnvoll ist.