Server-Side Rendering (SSR): Definition, Vorteile, Einsatz

Was ist Server-Side Rendering (SSR)?

Beim serverseitigen Rendering (SSR) baut der Server das HTML einer Seite, sobald eine Anfrage eintrifft, und schickt es fertig an den Browser. Der Browser kann Inhalte sofort anzeigen, danach lädt JavaScript und macht die Seite interaktiv. Beim clientseitigen Rendering (CSR) liefert der Server dagegen nur eine fast leere Hülle, und der Browser baut die Seite mit JavaScript auf.

Frameworks wie Next.js, Nuxt, SvelteKit und Remix unterstützen SSR, und die meisten erlauben die Wahl des Render-Modus pro Route. SSR passt zu Seiten, deren Inhalt von der Anfrage abhängt: Suchergebnisse, Ansichten für angemeldete Nutzer, Live-Bestände und Seiten, die indexierbar sein müssen.

So funktioniert SSR

1. Der Browser fragt /products/42 an.
2. Der Server lädt die Daten, führt den Komponentenbaum aus und erzeugt das HTML.
3. Der Server schickt das HTML, und der Browser zeigt es sofort an.
4. Der Browser lädt das JavaScript-Bundle.
5. Das Skript hydratisiert die Seite: Es hängt Event-Handler an das vorhandene HTML, und die Seite wird interaktiv.

Zwischen Schritt 3 und 5 ist die Seite sichtbar, reagiert aber unter Umständen noch nicht auf Klicks.

SSR im Vergleich zu anderen Rendering-Strategien

SSR kann auch am Edge laufen, nah beim Nutzer. Das senkt die Netzwerklatenz, begrenzt aber, welcher Code dort ausgeführt werden darf.

Ein minimales Beispiel

Ohne Framework ist SSR eine Funktion, die einen HTML-String zurückgibt. Diese Express-Route rendert eine React-Komponente auf dem Server:

import { renderToString } from 'react-dom/server';
import App from './App';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<!DOCTYPE html>
<html>
  <body>
    <div id="root">${html}</div>
    <script src="/client.js"></script>
  </body>
</html>`);
});

Der Browser lädt anschließend client.js, das mit hydrateRoot an das Markup andockt. Frameworks automatisieren diese Verdrahtung samt Routing, Datenladen und Code-Splitting.

Wann SSR passt

• Personalisierte Seiten. Das HTML hängt davon ab, wer fragt.
• Häufig wechselnde Daten. Preise, Lagerbestände, Nachrichten.
• Indexierbare Seiten mit dynamischen Daten. Produkt- und Suchseiten, die Crawler als HTML lesen müssen.
• Regionsspezifische Inhalte. Währung, Sprache oder Rechtstexte pro Anfrage.

Wann ein anderer Ansatz besser ist

• Marketing- und Dokumentationsseiten. SSG über ein CDN ist schneller und günstiger.
• Dashboards hinter dem Login ohne SEO-Bedarf. CSR ist einfacher zu hosten.
• Gemischte Websites. Statische Landingpages, SSR für den Katalog, CSR für die App.

Die Kosten der Hydration

Hydration ist der Preis von SSR. Der Browser lädt dieselben Komponenten noch einmal und führt sie aus, um das Verhalten anzuhängen. Laut web.dev (Rendering im Web) kann das Total Blocking Time und Interaction to Next Paint verschlechtern, auch wenn der First Contentful Paint besser wird: Die Seite wirkt bereit, reagiert aber noch nicht. Streaming-SSR (HTML in Teilen senden), React Server Components und Island-Architekturen wie bei Astro versuchen, die auszuführende JavaScript-Menge zu verkleinern.

Häufige SSR-Fehler

• Browser-APIs auf dem Server nutzen. window is not defined ist der Klassiker.
• Unterschiedliche Ausgabe auf Server und Client. Ein Zeitstempel oder eine Zufalls-ID lässt die Hydration warnen oder scheitern.
• Langsames Laden von Daten im Render. Der Browser bekommt nichts, bis die langsamste Abfrage fertig ist.
• Kein Caching. Jede Anfrage berechnet die Seite neu. Cachen Sie alles Nicht-Persönliche und markieren Sie persönliche Seiten mit Cache-Control: private.
• Speicherlecks. Ein Render-Server läuft tagelang, ein kleines Leck pro Anfrage summiert sich.
• Schwere Arbeit in der Auth-Middleware. Sie verzögert jede Antwort.

SSR und Performance-Tests

SSR verlagert die Render-Arbeit vom Gerät jedes Besuchers auf Ihren Server, deshalb bestimmt Ihre Kapazität nun die Seitengeschwindigkeit. Der Time to First Byte ist die Kennzahl, auf die es ankommt: web.dev bewertet 0,8 Sekunden oder weniger als gut und über 1,8 Sekunden als schlecht und weist darauf hin, dass eine serverseitig gerenderte Seite einen höheren TTFB, aber bessere Werte bei First Contentful Paint und Largest Contentful Paint haben kann als eine clientseitig gerenderte.

Eine einzelne Anfrage sagt wenig aus. Führen Sie einen Lasttest gegen Ihre wichtigsten SSR-Routen mit realistischem Traffic durch und beobachten Sie, wie sich TTFB und Fehlerrate bei steigender Nutzerzahl verändern. Danach verfolgen Sie die Core Web Vitals mit dem Page-Speed-Monitoring über die Zeit. Zur Frage der Single-Page-Apps siehe Lasttests für Single-Page-Anwendungen, gegen Rückschritte helfen Performance-Budgets für Web-Apps.

Häufige Fragen: Server-Side Rendering

Ist SSR besser als SSG?

Keines ist generell besser. SSG passt zu Inhalten, die sich selten ändern, weil das HTML einmal gebaut und über ein CDN ausgeliefert wird. SSR passt zu Inhalten, die sich pro Anfrage oder Nutzer ändern. Viele Websites nutzen beides.

Löst SSR die SEO automatisch?

Es stellt sicher, dass Crawler vollständiges HTML erhalten. Sie brauchen trotzdem gute Titel, Meta-Tags, strukturierte Daten, interne Links und ordentliche Core Web Vitals.

Ist SSR langsamer als CSR?

Das hängt von der Metrik ab. Der Server braucht Zeit für den Seitenaufbau, daher ist der TTFB meist höher. Die erste Darstellung kommt meist früher, weil das HTML fertig ankommt. Die Interaktivität hängt davon ab, wie viel JavaScript hydratisiert werden muss.

Kann ich SSR und CSR in einer App mischen?

Ja. Next.js, Nuxt und SvelteKit erlauben die Wahl des Render-Modus pro Route: Öffentliche Seiten nutzen SSR, ein Dashboard hinter dem Login bleibt clientseitig.

Wie senke ich den TTFB bei einer SSR-Website?

Cachen Sie Seiten und Daten ohne Personenbezug, beschleunigen oder parallelisieren Sie die Abfragen hinter dem Render, streamen Sie die Antwort und erwägen Sie Rendering am Edge. Messen Sie nach jeder Änderung erneut unter Last.

Ist SSR dasselbe wie React Server Components?

Nein. SSR erzeugt beim ersten Laden HTML auf dem Server, und der volle Komponentencode wird trotzdem zum Hydratisieren an den Browser geschickt. Server Components laufen nur auf dem Server und senden für ihren Teil des Baums keinen Komponentencode. Oft werden beide kombiniert.