Server Components in Next.js – was sich im Frontend-Alltag ändert

Mit dem App Router hat Next.js das Frontend-Denken spürbar verschoben: Server Components sind seit React 18 und dem App Router der Standard. Wer aus der Welt der klassischen Single-Page-App kommt, muss ein paar Gewohnheiten überdenken – der Gewinn ist aber real.

Server zuerst – Client nur, wenn nötig

Im App Router ist jede Komponente zunächst eine Server Component. Sie rendert auf dem Server, liefert HTML aus und schickt kein JavaScript für diese Komponente an den Browser. Das Ergebnis: kleinere Bundles und schnellere Seiten.

// Server Component (Standard) – läuft nur auf dem Server, kein Client-JS.
// Daten werden direkt geladen, kein useEffect, kein API-Umweg.
export default async function Produktliste() {
    const produkte = await getProdukte();
    return (
        <ul>
            {produkte.map((p) => <li key={p.id}>{p.name}</li>)}
        </ul>
    );
}

Sobald es interaktiv wird – State, Klicks, Effekte, Browser-APIs – braucht es eine Client Component. Die wird mit einer Direktive am Dateianfang markiert:

'use client';
import { useState } from 'react';

export default function Zaehler() {
    const [n, setN] = useState(0);
    return <button onClick={() => setN(n + 1)}>Klicks: {n}</button>;
}

Die Grenze richtig ziehen

'use client' markiert die Grenze, ab der das Client-Bundle beginnt – alles darunter im Baum wird ebenfalls zum Client. Deshalb die Faustregel:

Server als Standard lassen, 'use client' so weit wie möglich nach unten schieben. Nur die wirklich interaktiven Blätter werden Client-Komponenten – der Rest bleibt schlank auf dem Server.

Was das im Alltag bringt

• Weniger Client-JavaScript – der Browser lädt nur, was er für die Interaktion wirklich braucht.
• Datenladen dort, wo die Daten sind – direkt im async-Server-Component, ohne Round-Trip über eine eigene API.
• Secrets bleiben serverseitig – Tokens und Datenbankzugriffe verlassen den Server nicht.

Stolpersteine

• In Server Components gibt es keine Hooks und keine Event-Handler – das ist Client-Terrain.
• Über die Server-Client-Grenze wandern nur serialisierbare Props – keine Funktionen, keine Klassen.
• Interaktive Bibliotheken erwarten oft 'use client' – ein häufiger erster Fehler ist die vergessene Direktive.

Fazit

Server Components sind kein Selbstzweck, sondern verschieben die Arbeit dorthin, wo sie am günstigsten ist: Statisches und Datenlastiges auf den Server, Interaktives auf den Client. Wer die Grenze bewusst zieht, bekommt schnellere Seiten mit weniger Ballast – und schreibt nebenbei klarer strukturierten Code.