SSR vs. CSR vs. SSG: So funktioniert Rendering im Web

SSR vs. CSR vs. SSG ist ein Vergleich von Rendering-Strategien danach, wo und wann das HTML entsteht: zur Build-Zeit, auf dem Server oder im Browser. Diese eine Achse – wo und wann – bestimmt SEO, Performance, Datenaktualität und Kosten; alles andere folgt daraus. Dazu die Klarstellung des Backend-Entwicklers, die Frontend-Leitfäden vergraben: Rendering ist eine Frontend-Frage, die Daten sind eine Backend-Frage. Alle drei Strategien rufen dieselbe API auf; sie unterscheiden sich nur im Moment des Aufrufs.

Das Wichtigste in Kürze

Dieselben Daten, drei Aufrufzeitpunkte

// JavaScript — the SAME API call, consumed three ways.
// Rendering is a FRONTEND choice; the data is a BACKEND concern.
async function getPosts() {
  const q = new Parse.Query('Post').equalTo('published', true).limit(20);
  return q.find(); // one backend endpoint — the ONLY thing that changes is WHEN
}

// SSG — called at BUILD time; data baked into static HTML, served from a CDN.
// SSR — called PER REQUEST on the server; fresh HTML sent to the browser.
// CSR — called FROM THE BROWSER after load; the client builds the DOM.
// You don't change the backend to switch rendering — only when/where you fetch.

// Flutter / Dart — Back4app Flutter SDK
// Whatever the rendering strategy, the data comes from one backend API.
Future<List<ParseObject>> getPosts() async {
  final q = QueryBuilder<ParseObject>(ParseObject('Post'))
    ..whereEqualTo('published', true)
    ..setLimit(20);
  return (await q.query()).results?.cast<ParseObject>() ?? [];
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Swift — Back4app Swift SDK
// Whatever the rendering strategy, the data comes from one backend API.
func getPosts() async throws -> [Post] {
    try await Post.query("published" == true).limit(20).find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Kotlin — Back4app Android SDK
// Whatever the rendering strategy, the data comes from one backend API.
fun getPosts(): List<ParseObject> {
    val q = ParseQuery.getQuery<ParseObject>("Post")
    q.whereEqualTo("published", true)
    q.limit = 20
    return q.find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

Ein getPosts(), ein Backend-Endpoint. SSG ruft es zur Build-Zeit auf und backt das Ergebnis in statisches HTML; SSR ruft es je Anfrage auf dem Server auf und schickt frisches HTML; CSR ruft es aus dem Browser nach dem Laden auf. Sie ändern nie das Backend, um das Rendering zu ändern – nur den Moment und den Ort des Abrufs. Genau diese Tatsache macht aus einem verwirrenden Dreiervergleich eine einzige Entscheidung.

SSR vs. CSR vs. SSG nebeneinander

Die Metriken, ehrlich betrachtet

Die Trade-offs, die kein Vergleich sauber benennt. SSG gewinnt die Time to First Byte klar und beständig – ein CDN reicht eine vorgefertigte Datei zurück. SSR erhöht die TTFB (der Server muss rendern, bevor er antworten kann), schlägt CSR aber weiterhin beim ersten Bildaufbau und liefert frische Daten. CSR hat eine schnelle TTFB (die Shell ist winzig), aber einen langsamen ersten Bildaufbau und eine langsame Time to Interactive, weil nichts sichtbar ist, bevor das Bundle läuft. Und der Punkt, über den alle hinweggehen: SSR und SSG beheben die TTI nicht. Beide schicken HTML, das fertig aussieht, und danach läuft trotzdem die Hydration – das Laden, Parsen und Ausführen des JavaScripts, das die Interaktivität anhängt. Das ist die Lücke “sieht fertig aus, ist aber nicht klickbar”, und deshalb ist die Rechnung für ausgeliefertes JS die eigentliche Interaktivitätssteuer – der Grund für Islands, partielle Hydration und Server Components, die weniger davon ausliefern.

Das Spektrum 2026: ISR, Streaming, RSC

Das Trio ist eine didaktische Vereinfachung; in der Produktion liegt ein Spektrum. ISR (Incremental Static Regeneration) liefert statische Seiten aus, erzeugt sie aber in einem Intervall oder auf Anforderung neu – SSG-Tempo mit periodischer Aktualität, um den Preis gelegentlich veralteter Inhalte. Streaming-SSR schickt HTML in Stücken, während es entsteht, sodass die Shell in wenigen Dutzend Millisekunden erscheint, während langsame Inhalte dahinter nachströmen. Server Components laufen ausschließlich auf dem Server, liefern für nicht interaktive Teile null JavaScript aus und können Daten direkt lesen – die jüngste Antwort auf die Kosten der Hydration. Keines davon ändert den Vertrag mit dem Backend; sie geben feinere Kontrolle darüber, wann sich das HTML formt und wie viel JS darauf folgt – dieselbe Achse, um die sich dieser ganze Eintrag dreht.

Je Route, nicht je App

Der gedankliche Fortschritt, der die meisten “Welches denn nun?”-Debatten auflöst: Sie wählen keine Strategie für die gesamte Website. Eine einzelne App mischt sie regelmäßig – eine statisch generierte Marketing-Startseite, ein per ISR neu erzeugter Produktkatalog, ein serverseitig gerendertes personalisiertes Dashboard und clientseitig gerenderte interaktive Widgets – und jede Route entscheidet nach ihrem eigenen Bedarf. Die Frage lautet nie “SSR oder CSR oder SSG für meine App?”, sondern “welches für diese Seite?”, und die Antwort folgt den Daten der Seite: für alle gleich und stabil → statisch; personalisiert oder frisch → Server; hinter einer Anmeldung und hochinteraktiv → Client.

Welche Strategie je Seite? Entscheidungsmatrix

Typische Anwendungsfälle

• Content-Seiten – SSG plus CDN für sofortige, crawlerfreundliche Seiten (das JAMstack-Muster).
• Onlinehandel – Katalogseiten per ISR, Warenkorb und Kasse per SSR, interaktive Filter per CSR – drei Strategien, ein Shop.
• SaaS-Dashboards – CSR hinter einer Anmeldung, wo SEO nicht zählt, Interaktivität dagegen schon.
• Nachrichten und Publizieren – SSR oder ISR für Aktualität bei gutem SEO.
• PWAs – eine gerenderte Shell plus clientseitige Interaktivität und Offline-Caching.

Grenzen und Trade-offs

• Das SEO-Risiko von CSR ist real, wird aber überzeichnet. Crawler rendern JavaScript mit einem Budget; abseits des indexierbaren Pfads ist CSR in Ordnung, darauf ein Wagnis – Nuance statt Dogma.
• SSR kostet Serverrechenzeit. Jede Anfrage zu rendern hat einen Preis bei der TTFB und in der Infrastruktur, den eine statische, vom CDN gelieferte Datei nicht hat.
• Der Aktualitätsrückstand von SSG. Daten aus der Build-Zeit bleiben veraltet bis zum nächsten Build; große oder schnell wechselnde Seiten brauchen ISR oder lange Builds.
• Hydration ist die versteckte Steuer. Serverseitig gerendertes HTML liefert dennoch JS aus, um interaktiv zu werden; erster Bildaufbau schnell, erster Klick nicht zwangsläufig.
• Mischen erhöht die kognitive Last. Rendering je Route ist mächtig und bedeutet, über mehrere Abrufzeitpunkte in einer App nachzudenken – die Flexibilität hat ihren Preis in Komplexität.

Rendering mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie ist die Konstante unter der Rendering-Entscheidung: Die REST- und GraphQL-APIs versorgen SSG zur Build-Zeit, SSR je Anfrage auf dem Server und CSR aus dem Browser – derselbe Endpoint, den die Code-Tabs zeigen, konsumiert zu drei verschiedenen Zeitpunkten. Die Strategie einer Route zu wechseln rührt das Backend also nie an. Der Perspektivwechsel, mit dem dieser Artikel beginnt, wird damit zum praktischen Vorteil: Weil Rendering eine Frontend-Entscheidung ist und die Daten hinter einer stabilen API mit eigener Authentifizierung und eigenen Berechtigungen liegen, kann ein Team den Blog vorab bauen, das Dashboard serverseitig rendern und die App-Shell clientseitig rendern – alles gegen dasselbe Back4app-Backend, Seite für Seite gewählt, ohne darunter etwas zu ändern.