Die Rendering-Strategie beeinflusst Ladegeschwindigkeit, SEO, Serverkosten und wie "live" Ihre Daten sein können. Die falsche Wahl ist eine häufige Ursache sowohl für langsame Seiten als auch für unnötige Infrastrukturkosten.
Die drei Ansätze
| Ansatz | HTML wird erzeugt | Am besten geeignet für | Kompromiss |
|---|---|---|---|
| Statisch (SSG) | Beim Build | Marketing-Seiten, Docs, Blogs | Content-Updates brauchen einen Rebuild oder On-Demand-Revalidierung |
| Server-Side Rendering (SSR) | Pro Anfrage, auf dem Server | Seiten mit frischem, personalisiertem oder SEO-kritischem Content | Serverkosten pro Anfrage; mehr bewegliche Infrastruktur |
| Client-Side Rendering (CSR) | Im Browser, nach dem Laden von JS | Authentifizierte Apps, Dashboards, stark interaktive Tools | Langsamerer erster Bildaufbau; schwächeres SEO im Standardfall |
Wie sich das in der Praxis darstellt
Statisch — der Server (oder das CDN) hat die HTML-Datei bereits erzeugt. Eine Besucheranfrage ist ein Datei-Lookup. Schnellstmögliche Antwort, null Berechnung pro Anfrage.
SSR — der Server führt bei jeder Anfrage Ihren Anwendungscode aus, holt die benötigten Daten und liefert fertiges HTML zurück. Der Besucher sieht den Inhalt sofort, aber der Server arbeitet jedes Mal.
CSR — der Server liefert eine fast leere HTML-Hülle. Der Browser lädt JavaScript herunter, führt es aus, holt Daten über API-Aufrufe und rendert die Seite. Hervorragend für app-artige Interaktivität, schwächer für den allerersten Eindruck.
Ein Entscheidungsframework
Muss die Seite in der Suche ranken oder von KI-Systemen zitiert werden?
Wenn ja, tendieren Sie zu statisch oder SSR. Verwetten Sie Auffindbarkeit nicht auf JavaScript-Ausführung.
Ändert sich der Inhalt pro Anfrage oder pro Nutzer?
Personalisierte Dashboards, eingeloggte Ansichten und Echtzeitdaten sprechen für SSR oder CSR gegenüber statisch.
Wie oft ändert sich der zugrunde liegende Content?
Selten wechselnder Content (Docs, Marketing-Seiten) ist ein starker Kandidat für statisch, auch mit On-Demand-Revalidierung für gelegentliche Updates.
Wie hoch ist der Interaktivitätsgrad nach dem Laden?
Stark interaktive, app-artige Erlebnisse (Drag-and-Drop, Live-Editoren, komplexe Dashboards) sind naturgemäß CSR-lastig, sobald die anfängliche Hülle steht.
Pros
- +Statisch: schnellste Antwort, günstigstes Hosting, am einfachsten abzusichern
- +SSR: frische Daten beim ersten Bildaufbau, starkes SEO, funktioniert ohne Client-JS
- +CSR: reiche Interaktivität, geringere Serverlast pro Interaktion nach dem initialen Laden
Cons
- −Statisch: Content-Updates erfordern einen Rebuild oder einen Revalidierungsschritt
- −SSR: Serverkosten und Komplexität skalieren mit dem Traffic
- −CSR: schwächerer erster Bildaufbau und Standard-SEO ohne zusätzlichen Aufwand
Strategien auf einer Website mischen
Die meisten produktiven Websites sind nicht "nur SSR" oder "nur statisch". Eine typische Aufteilung:
- Marketing-Seiten und dieser Ressourcenbereich: statisch, bei Veröffentlichung neu gebaut
- Produktseiten mit Preisen oder Lagerbeständen, die sich ändern: SSR oder statisch mit Revalidierung
- Authentifiziertes Portal oder Dashboard: CSR, da SEO nicht zählt und Interaktivität wichtiger ist
Pro Route statt pro Projekt zu entscheiden ist meist die faulere und zugleich korrektere Antwort, als eine Strategie für eine gesamte Anwendung festzulegen.
FAQ
FAQ
Was ist der Unterschied zwischen SSR und CSR?+
SSR (Server-Side Rendering) baut das HTML bei jeder Anfrage auf dem Server, sodass der Browser eine vollständige Seite erhält. CSR (Client-Side Rendering) sendet eine weitgehend leere HTML-Hülle und baut die Seite erst im Browser mit JavaScript, nachdem sie geladen wurde.
Ist statisches Rendering schneller als SSR?+
In der Regel ja, für Seiten, die keine Daten pro Anfrage benötigen, da statisches HTML einmal beim Build erzeugt und direkt aus einem CDN ausgeliefert wird, ohne Serverberechnung pro Besuch.
Kann eine einzelne Website SSR, CSR und Static Rendering mischen?+
Ja. Die meisten modernen Frameworks unterstützen unterschiedliches Rendering pro Route — statische Marketing-Seiten, server-gerenderte Produktseiten und clientseitig gerenderte, authentifizierte Dashboards innerhalb einer Codebasis.
Verwandte Ressourcen
Headless CMS: Was es ist, wann Sie eines nutzen sollten und wann nicht
Eine verständliche Erklärung der Headless-CMS-Architektur, wie sie sich von traditionellen CMS-Plattformen unterscheidet, und eine praktische Checkliste, um zu entscheiden, ob Ihr Team tatsächlich eines braucht.
EngineeringWebsite-Architektur erklärt: Ebenen, Muster und wie Sie die richtige wählen
Was Website-Architektur tatsächlich bedeutet, welche Ebenen dazugehören, die wichtigsten Muster von heute und ein praktisches Framework, um anhand echter Rahmenbedingungen die richtige Wahl zu treffen.
GuidesWebsite-Performance-Checkliste für moderne Business-Sites
Eine praktische Performance-Checkliste zu Core Web Vitals, Asset-Strategie, Fonts, Caching und dem, was auf Marketing- und Product-Sites wirklich Conversion bewegt.
Newsletter
Produktnotizen, kein Rauschen.
Gelegentliche Frameworks zu Portalen, SaaS-MVPs und Automatisierung.