Next.js: Das React-Framework für produktionsreife Webanwendungen

React ist eine mächtige Bibliothek für den Aufbau von Benutzeroberflächen – aber auf dem Weg zur fertigen Webanwendung fehlen viele Bausteine: Routing, Datenabruf, Rendering-Strategien, Performance-Optimierung, API-Endpunkte. Next.js von Vercel schließt genau diese Lücke. Als vollständiges React-Framework liefert es alles, was für produktionsreife Webanwendungen benötigt wird – von der Entwicklungsumgebung bis zum Deployment.

Was ist Next.js?

Next.js ist ein Open-Source-Framework für React, das serverseitiges Rendering, statische Seitengenerierung und clientseitiges Rendering in einem einzigen Werkzeug vereint. Es wurde 2016 von Vercel veröffentlicht und hat sich seitdem zum de-facto-Standard für React-Anwendungen entwickelt, die mehr als eine einfache Single Page Application darstellen sollen.

Next.js übernimmt unter anderem:

Die offizielle Next.js-Dokumentation ist einer der besten Einstiege in das Framework.

App Router vs. Pages Router

Seit Next.js 13 gibt es zwei parallele Router-Ansätze, die beide offiziell unterstützt werden:

Der Pages Router (klassisch) basiert auf dem pages/-Verzeichnis. Jede Datei in diesem Verzeichnis wird automatisch zu einer Route. Dieser Ansatz ist stabil, gut dokumentiert und wird in bestehenden Projekten weiterhin unterstützt.

Der App Router (seit Next.js 13, stabil ab 14) nutzt das app/-Verzeichnis und basiert auf React Server Components. Er bietet feingranularere Kontrolle über das Rendering, unterstützt verschachtelte Layouts nativ und ermöglicht Server-seitige Datenabfragen direkt in Komponenten ohne getServerSideProps.

Für neue Projekte empfiehlt das Next.js-Team den App Router. Bestehende Pages-Router-Projekte können schrittweise migriert werden.

React Server Components

Der App Router basiert auf React Server Components (RSC) – einer Architektur, bei der Komponenten standardmäßig auf dem Server gerendert werden. Server Components können:

Für interaktive Elemente (Event-Handler, useState, useEffect) werden Client Components mit der Direktive 'use client' am Dateianfang deklariert. Das Mischen beider Typen in einer Anwendung ist problemlos möglich.

Rendering-Strategien

Next.js bietet drei grundlegende Rendering-Strategien, die sich kombinieren lassen:

Static Site Generation (SSG)

Seiten werden beim Build-Prozess einmalig generiert und als statische HTML-Dateien ausgeliefert. Optimal für Inhalte, die sich selten ändern (Blog-Posts, Dokumentation, Produktseiten). Maximale Performance durch CDN-Caching.

Server-Side Rendering (SSR)

Seiten werden bei jedem Request auf dem Server frisch generiert. Ideal für personalisierte Inhalte oder Daten, die sich häufig ändern (Dashboard, Suchergebnisse). Höhere Serverauslastung, aber stets aktuelle Daten.

Incremental Static Regeneration (ISR)

Eine Kombination aus beiden: Seiten werden statisch generiert, können aber nach einer definierten Zeit oder per Webhook im Hintergrund neu generiert werden, ohne den gesamten Build-Prozess neu anstoßen zu müssen. Ideal für Content-heavy Sites mit gemischten Anforderungen.

Tipp: Nutzen Sie im App Router das revalidate-Attribut in Fetch-Aufrufen, um ISR auf Komponenten-Ebene zu steuern: fetch(url, { next: { revalidate: 3600 } }) regeneriert den Cache stündlich. Mit revalidate: 0 erzwingen Sie SSR, mit revalidate: false statisches Caching ohne Ablaufzeit.

Datei-basiertes Routing im App Router

Im app/-Verzeichnis definiert die Ordnerstruktur die URL-Struktur:

Bild-Optimierung

Die next/image-Komponente optimiert Bilder automatisch: Sie konvertiert in moderne Formate (WebP, AVIF), passt die Größe an den Viewport an, verzögert das Laden nicht sichtbarer Bilder (Lazy Loading) und verhindert Cumulative Layout Shifts (CLS) durch Platzhalter-Reservierung.

import Image from 'next/image';

<Image
  src="/hero.jpg"
  alt="Hero-Bild"
  width={1200}
  height={630}
  priority
/>
Achtung: Externe Bildquellen müssen in der next.config.js unter images.remotePatterns explizit freigegeben werden. Ohne diese Konfiguration verweigert Next.js das Laden externer Bilder aus Sicherheitsgründen. Vergessen Sie nicht, nach jeder Änderung an der Konfigurationsdatei den Entwicklungsserver neu zu starten.

Vercel-Deployment

Next.js und Vercel sind aufeinander abgestimmt: Ein git push auf den Hauptbranch löst automatisch ein Deployment aus. Vercel erkennt Next.js-Projekte automatisch und konfiguriert Serverless Functions, Edge Functions und CDN-Verteilung ohne weiteres Zutun. Preview-Deployments für Pull Requests sind im kostenlosen Plan inklusive.

Framework-Vergleich

Framework Basis Rendering Stärke Besonderheit
Next.js React SSG, SSR, ISR, RSC Vielseitigkeit, Ökosystem App Router, Vercel-Integration
Remix React SSR-fokussiert Web-Standards, progressive Enhancement Nested Routes, Resource Routes
Astro Framework-agnostisch SSG, SSR (optional) Minimales JS, Content-Sites Islands Architecture
Nuxt Vue SSG, SSR, ISR Vue-Ökosystem Auto-Imports, Nuxt Modules

FAQ zu Next.js

Muss ich React kennen, um Next.js zu lernen?
Grundlegende React-Kenntnisse sind empfohlen, aber nicht zwingend erforderlich. Die offizielle Next.js-Dokumentation bietet einen eigenen Einsteigerkurs, der React-Grundlagen einschließt. Wer React bereits kennt, wird Next.js schnell produktiv einsetzen können.
Kann ich Next.js ohne Vercel deployen?
Ja. Next.js lässt sich auf jedem Node.js-Server, in Docker-Containern, auf AWS Lambda oder als statischer Export deployen. Alternativ bieten sich Plattformen wie Netlify, Railway, Render oder ein eigener VPS an. Vercel ist die komfortabelste Option, aber keine Pflicht.
Was ist der Unterschied zwischen getStaticProps und Server Components?
getStaticProps ist das Datenabruf-Muster des Pages Routers: Eine Funktion exportiert Daten für die Seite zur Build-Zeit. Im App Router wird stattdessen direkt in asynchronen Server Components mit await fetch() oder Datenbank-Abfragen gearbeitet. Das Ergebnis ist ähnlich, der Code aber deutlich schlanker.
Wie groß ist der Performance-Unterschied zwischen SSG und SSR?
Statisch generierte Seiten (SSG) sind in der Regel deutlich schneller, da sie direkt vom CDN ausgeliefert werden, ohne Server-Processing. SSR-Seiten haben je nach Server-Performance eine höhere Time to First Byte (TTFB). Für öffentliche, inhaltsbasierte Seiten sollte SSG oder ISR bevorzugt werden.