Server Components vs. Client Components: Was Ladezeit und SEO beeinflusst

Für Entscheider erklärt: Was auf dem Server passiert, was im Browser – und warum diese Aufteilung Ladezeit, Core Web Vitals und Rankings deiner Next.js-Website prägt. Mit Entscheidungsregeln.

Wenn deine Agentur eine Website mit Next.js baut oder du dich für eine individuelle Website statt WordPress entschieden hast, tauchen irgendwann die Begriffe „Server Components“ und „Client Components“ auf. Das klingt nach reinem Entwickler-Thema. Ist es zum Teil auch – aber die Entscheidung, welcher Teil deiner Website wo berechnet wird, bestimmt direkt, wie schnell die Seite lädt, wie zuverlässig Google sie liest und wie viele Besucher bis zur Anfrage durchhalten.

Dieser Artikel erklärt das Thema für Inhaber und Entscheider, nicht für Programmierer. Du bekommst:

• eine Kurzantwort, die du in drei Minuten verstanden hast
• eine Erklärung, was auf dem Server passiert, was im Browser – und warum das Ladezeit und SEO beeinflusst
• Entscheidungsregeln, welche Bausteine wohin gehören
• zwei kurze Code-Beispiele, damit du erkennst, wovon deine Agentur spricht
• typische Fehler aus unseren Audits und wie du sie ohne Technikwissen selbst erkennst
• Beispiele für Handwerksbetrieb, Praxis und Onlineshop
• eine Liste mit Fragen, die du deiner Agentur stellen kannst

Kurzantwort: Server rendert, Browser interagiert

In Next.js wird jeder Baustein einer Seite entweder auf dem Server oder im Browser des Besuchers verarbeitet. Server Components erzeugen fertiges HTML, das der Browser nur noch anzeigen muss. Ihr Programmcode verlässt den Server nie. Client Components werden zusätzlich als JavaScript an den Browser geschickt und dort ausgeführt, damit sie auf Klicks, Eingaben und Wischbewegungen reagieren können.

Für Ladezeit und SEO gilt deshalb eine einfache Regel: Alles, was man liest, gehört auf den Server. Nur das, was man bedient, gehört in den Browser. Wer diese Regel einhält, liefert weniger JavaScript aus, erreicht leichter die Schwellen der Core Web Vitals und stellt sicher, dass Google Texte und Links sofort im HTML findet. Wer sie verletzt, bezahlt mit langsamen Seiten auf dem Smartphone und mit Inhalten, die Google erst nach einem zweiten Verarbeitungsschritt sieht – oder gar nicht.

Was passiert wo: der Weg vom Server in den Browser

Damit die Regel Sinn ergibt, lohnt ein Blick darauf, was bei einem Seitenaufruf tatsächlich passiert. Ein Besucher tippt deine Adresse ein oder klickt in Google auf dein Ergebnis. Dann läuft in etwa Folgendes ab:

1. Der Browser fragt beim Server nach der Seite.
2. Der Server baut die Seite zusammen: Er holt Texte, Bilder und Daten, zum Beispiel Öffnungszeiten oder Produkte, und erzeugt daraus HTML.
3. Das HTML kommt beim Browser an und wird angezeigt. Ab hier sieht der Besucher etwas.
4. Der Browser lädt zusätzlich JavaScript herunter, führt es aus und verbindet es mit den angezeigten Elementen. Erst danach reagieren Buttons, Filter und Menüs. Entwickler nennen diesen Schritt Hydration.

Server Components enden nach Schritt 3. Client Components brauchen alle vier Schritte. Das ist der Kern des Themas: Jede Client Component verlängert Schritt 4, weil mehr JavaScript geladen, gelesen und ausgeführt werden muss.

Eine Nuance ist wichtig, weil sie oft falsch dargestellt wird: Auch Client Components werden in Next.js beim ersten Aufruf auf dem Server als HTML vorgerendert. Der Besucher sieht also meist nicht auf eine leere Fläche. Aber der Code der Client Component muss trotzdem zusätzlich an den Browser geschickt und dort ausgeführt werden. Und wenn eine Client Component ihre Daten erst im Browser nachlädt, fehlt genau dieser Inhalt im ausgelieferten HTML.

Ein Bild dazu: Ein Möbelhaus liefert dir einen Schrank montiert oder als Bausatz. Der montierte Schrank steht sofort. Der Bausatz ist flexibler, kostet dich aber Zeit und Werkzeug. Server Components sind der montierte Schrank, Client Components der Bausatz. Für eine ausziehbare Tastaturablage ist ein kleiner Bausatz in Ordnung. Für ein ganzes Zimmer willst du das nicht.

Server Components: Inhalte, die sofort da sind

In Next.js mit App Router ist jeder Baustein standardmäßig eine Server Component. Das ist bewusst so gewählt, weil die meisten Teile einer Unternehmenswebsite reine Darstellung sind:

• Überschriften, Fließtext, Listen, Leistungsbeschreibungen
• Navigation, Footer, Breadcrumbs und Teaser mit internen Links
• Bilder, Referenzen, Team-Vorstellung, Öffnungszeiten, Adresse
• Inhalte aus einem CMS, einer Datenbank oder einer Schnittstelle
• Metadaten wie Titel, Beschreibung und Canonical-Angabe

Für all das braucht der Browser keine Logik. Der Server holt die Daten, baut das HTML und ist fertig. Kein Programmcode dieser Bausteine landet beim Besucher. Das bedeutet weniger Datenvolumen, weniger Rechenarbeit auf dem Smartphone und Inhalte, die für Google und Besucher im ersten Moment vollständig sind. Nebeneffekt: Zugangsdaten für CMS, Datenbank oder Warenwirtschaft bleiben auf dem Server und werden im Browser nie sichtbar.

Client Components: Interaktion, die JavaScript braucht

Client Components sind Bausteine, die im Browser laufen müssen, weil sie auf den Besucher reagieren. Sie werden mit der Zeile "use client" am Anfang der Datei gekennzeichnet. Typische Fälle:

• Filter und Sortierung, die ohne Neuladen reagieren
• Tabs, Akkordeons, Bildergalerien, Slider
• Formulare mit Live-Prüfung der Eingaben oder mehreren Schritten
• Cookie-Banner und Einstellungen, die im Browser gespeichert werden
• Karten, Konfiguratoren, Rechner
• alles, was auf Bildschirmgröße, Scrollposition oder Mausbewegung reagiert

Client Components sind nicht schlecht. Sie sind der Grund, warum sich eine Website wie eine Anwendung anfühlen kann. Entscheidend ist der Zuschnitt: Die Client Component sollte so klein sein wie das interaktive Element selbst. Ein Filter über einer Leistungsliste ist eine Client Component. Die Leistungsliste, die Überschrift, der erklärende Text und die Links darunter bleiben Server Components.

Tipp: Wenn deine Agentur sagt „die Seite ist eine Client Component“, frag nach, warum. Für eine ganze Seite gibt es fast nie einen Grund. Meist ist irgendwo ein kleines interaktives Element, das die gesamte Seite mit sich in den Browser gezogen hat.

Warum die Aufteilung die Ladezeit beeinflusst

JavaScript ist der teuerste Bestandteil einer Website. Ein Bild wird heruntergeladen und angezeigt. JavaScript wird heruntergeladen, gelesen, ausgeführt und mit der Seite verbunden – auf dem Gerät des Besuchers. Auf einem modernen Laptop fällt das kaum auf. Auf einem älteren Mittelklasse-Smartphone im Mobilfunknetz, und damit bei einem großen Teil deiner Besucher, ist es der Unterschied zwischen „lädt sofort“ und „lädt irgendwann“.

Google misst die Nutzererfahrung über die Core Web Vitals. Die drei Kennzahlen und ihre Schwellen solltest du kennen, weil du sie in jedem Bericht wiederfindest:

Die Aufteilung in Server und Client Components ist einer der größten Hebel für INP und einer der wichtigsten für LCP. Wer Texte, Listen und Links serverseitig ausliefert, verkleinert das JavaScript-Paket oft erheblich und gibt dem Browser Luft für die Teile, die wirklich interaktiv sind. Was die Kennzahlen im Detail bedeuten, steht im Artikel Core Web Vitals erklärt; für den LCP kommt meist das Thema Bilder dazu, siehe LCP und Bilder mit next/image.

Auch die beste Aufteilung hilft wenig, wenn der Server selbst langsam antwortet. Antwortzeit, Caching und CDN erklären wir in TTFB, CDN und Caching. Beides zusammen ergibt eine schnelle Seite: Der Server antwortet schnell, und er liefert fertiges HTML statt eines Bausatzes.

Warum die Aufteilung SEO beeinflusst

Google kann JavaScript ausführen. Glaub niemandem, der behauptet, JavaScript-Websites seien für Google unsichtbar. Trotzdem gibt es drei gute Gründe, warum serverseitig gerenderte Inhalte für SEO sicherer sind.

Erstens: Rendering ist ein zweiter Schritt. Google liest zunächst das HTML, das dein Server ausliefert. Das Ausführen von JavaScript passiert in einem eigenen Verarbeitungsschritt, der später folgen kann. Inhalte und Links, die erst durch JavaScript entstehen, werden also später und mit mehr Unsicherheit erfasst. Bei häufigen Änderungen, vielen Seiten oder neuen Inhalten, die schnell ranken sollen, ist das ein Nachteil.

Zweitens: Interne Links müssen im HTML stehen. Google folgt Links, um deine Seiten zu finden und ihre Bedeutung zu verstehen. Wenn Navigation, Teaser oder Breadcrumbs erst durch Client-Logik erzeugt werden, kann diese Struktur für den Crawler schwächer ausfallen. Die technische Voraussetzung für jede interne Verlinkung ist deshalb: reguläre Links im ausgelieferten HTML.

Drittens: Ladezeit fließt in die Bewertung ein. Google nutzt die Core Web Vitals als Teil der Seitenerfahrung. Eine Seite, die wegen zu viel JavaScript die Schwellen reißt, hat es schwerer als eine schlanke Seite mit gleichem Inhalt. Und unabhängig von Google: Besucher, die fünf Sekunden auf einen Button warten, rufen nicht an.

Metadaten sind der vierte Punkt, den viele übersehen. Titel, Beschreibung und Canonical-Angabe gehören in das HTML, das der Server liefert. In Next.js gibt es dafür eine eigene Metadata-Funktion in Server Components. Wer diese Angaben im Browser nachträglich setzt, riskiert, dass Google die falschen oder gar keine Werte sieht. Das Gesamtbild zu Rendering, Metadaten und Indexierung steht im Next.js SEO Guide für den App Router.

Entscheidungsregeln: Server oder Client?

Drei Regeln reichen, um die allermeisten Fälle richtig einzuordnen. Sie sind so formuliert, dass du sie im Gespräch mit deiner Agentur benutzen kannst.

1. Was man liest, gehört auf den Server. Text, Überschriften, Bilder, Listen, Links, Preise, Öffnungszeiten. Immer.
2. Was man bedient, darf in den Browser – aber nur dieser Teil. Filter, Tabs, Slider, Formulare mit Live-Prüfung. Die Seite drumherum bleibt Server.
3. Daten werden auf dem Server geholt, nicht im Browser. Wenn ein Baustein Inhalte aus CMS, Datenbank oder Schnittstelle braucht, lädt sie der Server und gibt sie fertig an den Browser weiter. Der Browser lädt nur nach, was sich durch eine Aktion des Besuchers ändert.

Tipp: Wenn ein Baustein in beide Spalten passt, teile ihn. Die Frage ist nie „Ist die Referenzseite Server oder Client?“, sondern „Welcher kleine Teil der Referenzseite braucht wirklich den Browser?“.

Zwei kurze Code-Beispiele

Du musst keinen Code schreiben. Aber es hilft, die Struktur zu erkennen, wenn sie in einem Angebot oder Audit-Bericht auftaucht. So ist eine sauber aufgeteilte Leistungsseite in Next.js aufgebaut:

app/
  leistungen/
    page.tsx        Server Component: Überschrift, Text, Bilder, Links,
                    Daten aus dem CMS – alles fertig als HTML
    Filter.tsx      Client Component: nur das Filterfeld,
                    reagiert auf Eingaben des Besuchers

Die Seite holt die Daten auf dem Server und gibt sie als fertige Liste aus. Der Filter ist ein kleiner, eigenständiger Baustein, der die bereits geladene Liste im Browser eingrenzt. Entwickler nennen das eine „Client-Insel“: eine kleine interaktive Fläche in einem Meer aus serverseitigem HTML.

Das zweite Beispiel ist die einzige Zeile, an der du eine Client Component erkennst. Sie steht ganz oben in der Datei:

"use client";

Fehlt diese Zeile, ist der Baustein eine Server Component. Bitte deine Agentur, dir zu zeigen, in welchen Dateien sie steht. Steht sie in der Seitendatei selbst oder im Layout, das alle Seiten umschließt, läuft praktisch die gesamte Website als Bausatz im Browser.

Typische Fehler und wie du sie erkennst

In Audits sehen wir immer wieder dieselben Muster. Die gute Nachricht: Du kannst die meisten davon ohne Entwicklerwissen selbst erkennen.

Drei Prüfungen, die jeder in fünf Minuten durchführen kann:

1. Seitenquelltext ansehen. Rechtsklick auf die Seite, dann „Seitenquelltext anzeigen“. Suche mit der Tastenkombination Strg und F nach einem Satz aus dem Haupttext. Findest du ihn, ist der Inhalt im HTML. Findest du ihn nicht, entsteht er erst im Browser.
2. JavaScript ausschalten. In den Browser-Einstellungen lässt sich JavaScript für eine Seite deaktivieren. Lade die Seite neu. Texte, Bilder und Links sollten noch da sein. Nur Filter, Slider und Formulare dürfen ausfallen.
3. PageSpeed Insights ausführen. Gib deine Adresse ein und sieh dir die mobile Bewertung an. Achte auf INP, LCP und die Hinweise unter „Diagnose“, die JavaScript erwähnen.

Beispiele: Handwerk, Praxis und Onlineshop

Wie die Aufteilung in der Praxis aussieht, hängt vom Website-Typ ab. Drei Beispiele aus unserem Alltag mit Unternehmen aus Magdeburg und Sachsen-Anhalt:

Beim Handwerksbetrieb ist der Fall einfach: Fast alles ist Inhalt, die wenigen interaktiven Teile lassen sich sauber isolieren. Wer hier eine komplett clientseitige Website bekommt, bezahlt Ladezeit für nichts. Bei der Praxis ist die Terminbuchung oft ein externes Werkzeug, das als Client-Insel eingebunden wird – der Rest der Seite bleibt davon unberührt. Beim Onlineshop ist der Anteil an Interaktion höher, aber gerade dort zählt, dass Produktseiten mit Beschreibung und Preis serverseitig ankommen, weil sie ranken und verkaufen müssen.

Fragen, die du deiner Agentur stellen kannst

Du musst die Antworten nicht selbst prüfen können. Allein die Fragen zeigen, dass du das Thema kennst – und eine gute Agentur beantwortet sie gern konkret.

• Welche Teile der Website laufen als Client Components, und warum jeweils?
• Stehen alle Texte, Preise und internen Links im ausgelieferten HTML?
• Werden Inhalte aus dem CMS auf dem Server geladen oder erst im Browser?
• Wie groß ist das JavaScript-Paket der Startseite auf dem Smartphone?
• Welche LCP- und INP-Werte erreicht die Website mobil, gemessen mit echten Nutzerdaten?
• Werden Titel, Beschreibung und Canonical serverseitig gesetzt?
• Was passiert mit der Seite, wenn JavaScript im Browser ausfällt?

Diese Fragen gehören auch in die Abnahme vor dem Livegang, nicht erst in die Fehlersuche danach.

Tipp: Lass dir die Werte nicht nur aus dem Labor zeigen, sondern aus dem Feld: PageSpeed Insights zeigt oben „Nutzererfahrungen“ aus echten Chrome-Daten, sofern deine Seite genug Besucher hat. Diese Werte zählen für Google.

Kosten und Aufwand: Was ein Umbau realistisch bedeutet

Bei einer neuen Website entsteht durch eine saubere Aufteilung kein Mehraufwand – es ist die Art, wie Next.js gedacht ist. Achte darauf, dass das Angebot serverseitiges Rendering und die Core Web Vitals als Abnahmekriterium nennt.

Bei einer bestehenden Next.js-Website hängt der Aufwand von der Ausgangslage ab:

• Einzelne große Blöcke sind unnötig Client Components. Der häufigste Fall. Die Blöcke werden aufgeteilt, der interaktive Kern bleibt, der Rest wandert auf den Server. In vielen Projekten eine Sache von einigen Arbeitstagen.
• Die Seite lädt ihre Inhalte im Browser nach. Die Datenbeschaffung muss auf den Server verlagert werden. Höherer Aufwand, weil die Struktur angefasst wird, aber entsprechend großer Gewinn bei LCP und SEO.
• Die gesamte Website läuft clientseitig. Dann ist der Umbau eher ein Relaunch als eine Optimierung. Ob sich das lohnt, klärt ein Audit – und wenn ja, gehört ein Plan dazu, der Rankings schützt, siehe Relaunch ohne Rankingverlust.

Wenn du nicht weißt, in welcher Lage deine Website ist, ist der Website-Check der schnellste Weg, das herauszufinden. Wir messen die Kennzahlen, sehen uns die Struktur an und nennen dir konkret die Blöcke, die das JavaScript treiben.

Wann das Thema für dich keine Rolle spielt

Nicht jede Website braucht diese Diskussion. Drei Fälle, in denen du dir die Zeit sparen kannst:

• Deine Website läuft auf klassischem WordPress. Dort wird serverseitig mit PHP gerendert, die Frage stellt sich nicht. Ladezeitprobleme durch Page-Builder und Plugins haben eine andere Lösung.
• Deine Website ist ein Onepager ohne Interaktion. Ein paar Abschnitte, ein Kontaktformular, keine Filter. Wenn die Core Web Vitals grün sind, gibt es nichts zu optimieren.
• Die Kennzahlen sind bereits gut. Wenn LCP, INP und CLS mit echten Nutzerdaten unter den Schwellen liegen, ist die Aufteilung offenbar in Ordnung. Optimierung um der Optimierung willen bringt nichts.

Umgekehrt lohnt sich der Blick immer, wenn die Website in Next.js gebaut ist, mobil langsam wirkt oder Inhalte in Google nicht so erscheinen, wie sie sollten.

Nächster Schritt

Wenn du das selbst angehen willst: Führe die drei Prüfungen aus diesem Artikel durch, notiere die mobilen Werte für LCP und INP und stelle deiner Agentur die Fragen aus der Liste. Damit hast du in einer Stunde ein klares Bild, ob deine Website Inhalte serverseitig ausliefert oder als Bausatz im Browser zusammensetzt.

Wenn du lieber einen Partner hast, der das für dich prüft und umsetzt: Wir bauen Websites und Anwendungen mit Next.js von Anfang an serverseitig und schlank, und wir analysieren bestehende Seiten auf ihre größten JavaScript-Treiber – für Unternehmen aus Magdeburg, Sachsen-Anhalt und deutschlandweit.

• Webdesign mit Next.js von 22Orbit
• Individuelle Softwareentwicklung
• Kostenloser Website-Check
• Kostenloses Erstgespräch vereinbaren