--- term: 'SSR vs. CSR vs. SSG' seoTitle: 'SSR vs. CSR vs. SSG: Rendering-Muster, SEO und Metriken' headline: 'SSR vs. CSR vs. SSG: So funktioniert Rendering im Web' slug: ssr-vs-csr-vs-ssg category: frontend-web shortDefinition: '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.' relatedTerms: - jamstack - cdn-content-delivery-network - progressive-web-app-pwa - api contrastsWith: - jamstack aboutTerms: - 'Hydration' - 'ISR & Streaming' - 'TTFB / FCP / TTI' faq: - question: 'Was ist CSR (clientseitiges Rendering)?' answer: 'Der Server schickt eine nahezu leere HTML-Shell plus ein JavaScript-Bundle; der Browser lädt, parst und führt das JS aus, holt Daten von einer API und baut die Seite. Der Nutzer sieht einen leeren Bildschirm oder einen Spinner, bis das JavaScript läuft – beste Interaktivität, schlechtester erster Ladevorgang und schlechtestes SEO.' - question: 'Was ist SSR (serverseitiges Rendering)?' answer: 'Der Server erzeugt für jede Anfrage vollständiges HTML – er führt Code aus und holt Daten – und schickt ein Dokument, das sofort gezeichnet werden kann; anschließend wird es für die Interaktivität hydriert. Starkes SEO und schneller erster Bildaufbau mit stets frischen Daten, zum Preis von Serverrechenzeit und einer höheren Time to First Byte.' - question: 'Was ist SSG (statische Generierung)?' answer: 'Das HTML jeder Seite wird zur Build-Zeit vorab in statische Dateien gebaut und aus einem CDN ausgeliefert, ohne Serverarbeit je Anfrage. Die schnellste, günstigste und SEO-freundlichste Option – aber die Daten sind nur so frisch wie der letzte Build, und für unbekannte oder hochdynamische Routen passt sie schlecht.' - question: 'Was ist der Unterschied zwischen ihnen?' answer: 'Wo und wann das HTML entsteht: zur Build-Zeit (SSG), je Anfrage auf dem Server (SSR) oder zur Laufzeit im Browser (CSR). Alles andere – SEO, Performance, Datenaktualität, Kosten – folgt aus dieser einen Entscheidung.' - question: 'Welche Rendering-Strategie ist die beste für SEO?' answer: 'SSG und SSR, weil Crawler fertig ausgeformtes HTML erhalten. CSR ist am riskantesten, denn Bots müssen JavaScript ausführen, um den Inhalt zu sehen, was die Indexierung verzögert oder kosten kann. Die Nuance: Moderne Crawler rendern JavaScript durchaus, aber mit einem Budget – für nicht zu indexierende Oberflächen ist CSR also in Ordnung und für Inhalte, die ranken sollen, ein Wagnis.' - question: 'Was ist Hydration?' answer: 'Das Anhängen von JavaScript – Event-Listener und Zustand – an bereits gerendertes Server-HTML, damit eine statisch wirkende Seite interaktiv wird. Der Haken: Das JS muss trotzdem geladen, geparst und ausgeführt werden. Eine Seite kann also fertig aussehen und dennoch nicht klickbar sein, was die Time to Interactive verzögert, selbst wenn der erste Bildaufbau schnell war.' - question: 'Wann sollten Sie SSR statt SSG verwenden?' answer: 'SSG für Inhalte, die für alle gleich sind und sich selten ändern – Dokumentation, Blogs, Marketing. SSR für Seiten, die personalisiert oder durch Authentifizierung geschützt sind oder sich so häufig ändern, dass Daten aus der Build-Zeit veraltet wären. Der Standardrat: SSG bevorzugen und nur dort zu SSR greifen, wo Aktualität je Anfrage nötig ist.' - question: 'Gilt eine Strategie für die gesamte App?' answer: 'Nein – moderne Praxis ist die Wahl je Route, sogar je Komponente: statische Marketingseiten, per ISR neu erzeugte Katalogseiten, serverseitig gerenderte Dashboards und clientseitig gerenderte Widgets können alle in einer App leben. Rendering ist eine Entscheidung je Seite, nicht eine einmalige für die ganze Website.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Client-side rendering (CSR) — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Glossary/CSR' - name: 'Server-side rendering (SSR) — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Glossary/SSR' - name: 'Rendering patterns — patterns.dev' url: 'https://www.patterns.dev/' - name: 'Static site generator — Wikipedia' url: 'https://en.wikipedia.org/wiki/Static_site_generator' cta: title: 'Eine API, jede Rendering-Strategie' text: 'Die REST- und GraphQL-APIs von Back4app versorgen SSG zur Build-Zeit, SSR je Anfrage und CSR im Browser unverändert – wählen Sie das Rendering je Route; das Backend bleibt dasselbe.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-28' translationKey: ssr-vs-csr-vs-ssg --- **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](/glossary/de/api/) auf; sie unterscheiden sich nur im Moment des Aufrufs. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Die Achse | *Wo und wann* das HTML entsteht – Build · Server · Browser | | CSR | Der Browser baut es – beste Interaktivität, schlechtestes erstes Laden und SEO | | SSR | Der Server baut es je Anfrage – frisch, SEO-stark, höhere TTFB | | SSG | Vorab gebaut, vom [CDN](/glossary/de/cdn/) geliefert – am schnellsten, am günstigsten, veraltet bis zum Rebuild | | Der Perspektivwechsel | Dieselbe [API](/glossary/de/api/), drei Aufrufzeitpunkte – je Route, nicht je App | ## Dieselben Daten, drei Aufrufzeitpunkte **JavaScript:** ```javascript // 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 // Flutter / Dart — Back4app Flutter SDK // Whatever the rendering strategy, the data comes from one backend API. Future> getPosts() async { final q = QueryBuilder(ParseObject('Post')) ..whereEqualTo('published', true) ..setLimit(20); return (await q.query()).results?.cast() ?? []; } // SSG fetches at build, SSR fetches per request, CSR fetches in the client — // the endpoint is identical; only the timing and location differ. ``` **Swift:** ```swift // 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:** ```kotlin // Kotlin — Back4app Android SDK // Whatever the rendering strategy, the data comes from one backend API. fun getPosts(): List { val q = ParseQuery.getQuery("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 ```mermaid flowchart LR accTitle: Wo das HTML bei CSR, SSR und SSG entsteht accDescr: Beim clientseitigen Rendering schickt der Server eine leere Shell und ein JavaScript-Bundle, und der Browser holt die Daten von der API und baut die Seite. Beim serverseitigen Rendering holt der Server die Daten je Anfrage von der API und schickt vollständiges HTML, das anschließend hydriert wird. Bei der statischen Generierung wird das HTML zur Build-Zeit aus der API vorab gebaut und aus einem CDN ausgeliefert. Alle drei lesen dieselbe Backend-API. API[("Backend-API")] -->|"zur Build-Zeit"| SSG["SSG → statisches HTML → CDN"] API -->|"je Anfrage, Server"| SSR["SSR → volles HTML → Hydration"] API -->|"aus dem Browser"| CSR["CSR → Shell + JS → DOM bauen"] ``` | | CSR | SSR | SSG | | --- | --- | --- | --- | | HTML entsteht | Im Browser | Server, je Anfrage | Zur Build-Zeit | | TTFB | Schnell | **Höher** (rendert zuerst) | **Am schnellsten, konstant** | | Erster Bildaufbau (FCP) | Langsam | Schnell | Schnell | | Interaktiv (TTI) | Langsam | Nach der Hydration | Nach der Hydration | | SEO | Am riskantesten | Stark | Stark | | Datenaktualität | Live | Live | Stand des letzten Builds | | Kosten | Wenig Server | Server je Anfrage | Am günstigsten (statisch) | | Passend für | Dashboards, Apps | Personalisiert, frisch | Content, Doku, Marketing | ## 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 | Seitentyp | Rendering | | --- | --- | | Marketing, Landingpage, Blog, Doku | SSG | | Produktkatalog, Nachrichten, Feeds | ISR (statisch + periodische Auffrischung) | | Personalisiert, auth-geschützt, Warenkorb, Suche | SSR (oder Streaming) | | Dashboards, interne Werkzeuge | CSR | | Echtzeit, hochinteraktiv | CSR + [Live-Daten](/glossary/de/live-queries-echtzeit/) | | SEO-kritische Inhalte | Kein CSR – serverseitig rendern oder vorab bauen | ## Typische Anwendungsfälle - **Content-Seiten** – SSG plus [CDN](/glossary/de/cdn/) für sofortige, crawlerfreundliche Seiten (das [JAMstack](/glossary/de/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](/glossary/de/pwa/)** – 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](/glossary/de/automatisch-generierte-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](/glossary/de/authentifizierung-vs-autorisierung/) und eigenen [Berechtigungen](/glossary/de/zugriffskontrolllisten-acl/) 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.