Server-Side Rendering vs. Client-Side Rendering: Was wann passt

Kurz gefasst: Server-Side Rendering (SSR) erzeugt das HTML auf dem Server und liefert sofort sichtbare Inhalte. Das ist gut für SEO, für schnelle erste Anzeige und für Seiten, die öffentlich gefunden werden sollen. Client-Side Rendering (CSR) baut die Seite erst im Browser mit JavaScript auf und eignet sich für stark interaktive Anwendungen hinter einem Login, etwa Dashboards oder Editoren. Moderne Frameworks wie Next.js kombinieren beides: Inhalte kommen vom Server, interaktive Teile laufen im Browser.

Wie Server-Side Rendering und Client-Side Rendering funktionieren

Beim Client-Side Rendering schickt der Server eine fast leere HTML-Datei und ein JavaScript-Paket. Der Browser lädt das Skript, holt die Daten über eine API und baut daraus die Seite. Bis das passiert ist, sieht der Nutzer einen leeren Bildschirm oder einen Ladeindikator. Danach fühlt sich die Anwendung sehr flüssig an, weil Seitenwechsel ohne neuen Request an den Server auskommen.

Beim Server-Side Rendering erzeugt der Server für jede Anfrage das fertige HTML mit allen Inhalten. Der Browser kann es sofort anzeigen. Anschließend lädt JavaScript nach und macht die Seite interaktiv. Diesen Schritt nennt man Hydration.

Dazu kommen zwei verwandte Varianten. Bei der statischen Generierung (SSG) entsteht das HTML schon beim Build und wird über ein CDN ausgeliefert, was besonders schnell ist. Incremental Static Regeneration (ISR) erneuert solche statischen Seiten in festgelegten Abständen oder bei Änderungen, ohne die ganze Seite neu zu bauen.

Was die Wahl für SEO und Ladezeit bedeutet

Suchmaschinen und KI-Crawler

Google kann JavaScript ausführen, verarbeitet solche Seiten aber in einem zusätzlichen Schritt, was die Indexierung verzögern kann. Viele andere Crawler, darunter etliche Bots von KI-Suchdiensten und die Vorschaugeneratoren sozialer Netzwerke, führen JavaScript gar nicht oder nur eingeschränkt aus. Für Seiten, die gefunden werden sollen, ist serverseitig erzeugtes HTML deshalb die sichere Wahl.

Core Web Vitals

Googles Core Web Vitals messen Ladezeit des größten sichtbaren Elements (LCP), Reaktionsfähigkeit auf Eingaben (INP) und visuelle Stabilität (CLS). SSR und statische Seiten verbessern in der Regel den LCP, weil Inhalte früher sichtbar sind. Zu viel JavaScript, das bei der Hydration ausgeführt wird, kann dagegen den INP verschlechtern. Wie Sie solche Werte dauerhaft im Griff behalten, beschreibt unser Beitrag zu Performance-Budgets.

Wann welches Rendering-Modell passt

Statisch oder serverseitig

Marketingseiten, Blogs, Produktkataloge, Landingpages und Dokumentation profitieren von statischer Generierung oder SSR. Die Inhalte sind für alle gleich oder ändern sich selten, und gute Auffindbarkeit ist wichtig. Personalisierte Seiten mit häufig wechselnden Daten, etwa Suchergebnisse oder Kontoübersichten in einem Shop, sind typische Fälle für SSR.

Clientseitig

Interne Werkzeuge, Admin-Bereiche, Dashboards mit vielen Filtern und Editoren profitieren von CSR. Hier ist SEO irrelevant, Nutzer bleiben lange in der Anwendung, und eine schnelle Reaktion auf jede Eingabe zählt mehr als die erste Ladezeit. Eine klassische Single-Page-Application mit React und Vite ist dafür eine schlanke Lösung.

Die Mischform als Standard

In der Praxis bestehen die meisten Webanwendungen aus beidem: einer öffentlichen Seite, die gefunden werden soll, und einem eingeloggten Bereich mit viel Interaktion. Frameworks wie Next.js, Nuxt, SvelteKit, Remix oder Astro erlauben, das Rendering pro Seite oder sogar pro Komponente zu wählen. Warum wir uns für Next.js als Standard entschieden haben, erklären wir im Beitrag Next.js als Standard-Framework.

React Server Components und Streaming

Mit dem App Router von Next.js sind React Server Components der Standard. Komponenten laufen zunächst auf dem Server, holen dort ihre Daten und schicken nur das Ergebnis an den Browser. Nur Komponenten, die mit "use client" markiert sind, landen als JavaScript im Browser. Das verkleinert die Pakete deutlich. Mit Streaming und Suspense kann der Server zudem schnelle Teile einer Seite sofort senden und langsame Bereiche nachliefern, statt auf die langsamste Datenquelle zu warten. Was sich mit aktuellen Next.js-Versionen sonst geändert hat, lesen Sie in unserem Überblick zu Next.js 15.

Häufige Fragen (FAQ)

Ist Server-Side Rendering immer schneller?

Für die erste sichtbare Anzeige meist ja. SSR erhöht aber die Arbeit auf dem Server und kann die Antwortzeit verlängern, wenn Datenquellen langsam sind. Bei Interaktionen innerhalb einer laufenden Anwendung ist CSR oft gleich schnell oder schneller.

Braucht eine Anwendung hinter einem Login überhaupt SSR?

Nicht zwingend. Für reine Arbeitsoberflächen ist CSR eine gute Wahl. SSR kann trotzdem sinnvoll sein, wenn die erste Ansicht schnell erscheinen soll oder wenn sensible Logik auf dem Server bleiben soll.

Kann Google Seiten mit Client-Side Rendering indexieren?

Ja, Google führt JavaScript aus, allerdings mit Verzögerung und nicht immer vollständig. Andere Suchmaschinen und viele KI-Crawler sind weniger zuverlässig. Für Inhalte, die gefunden werden sollen, ist serverseitig erzeugtes HTML der sicherere Weg.

Lässt sich eine bestehende Single-Page-Application auf SSR umstellen?

Ja, meist schrittweise. Häufig werden zuerst die öffentlichen Seiten in ein Framework wie Next.js überführt, während der eingeloggte Bereich zunächst clientseitig bleibt.

Fazit

Die Rendering-Entscheidung treffen Sie am besten pro Seite. Öffentliche Inhalte gehören auf den Server, stark interaktive Arbeitsbereiche dürfen im Browser leben, und moderne Frameworks verbinden beides in einem Projekt. Wenn Sie eine Webanwendung mit dem passenden Rendering-Konzept planen, sprechen Sie mit uns über Webentwicklung mit React und Next.js.