Rendering beschreibt, wie Daten in das HTML umgewandelt werden, das der Browser schließlich darstellt. Wann und wo diese Umwandlung passiert, beeinflusst entscheidend die Nutzererfahrung.
Die gewählte Rendering-Strategie bestimmt unter anderem:
- Time-to-First-Byte (TTFB) und First Contentful Paint (FCP)
- Menge an JavaScript, die auf dem Gerät des Nutzers geladen und aktiviert wird
- Ort der Verarbeitung: beim Build, auf dem Server pro Anfrage oder komplett im Client
Diese Strategien existieren unabhängig von Frameworks: klassische Methoden wie CSR, SSG und SSR gibt es schon vor React. Mit React kam die vierte Strategie hinzu: React Server Components (RSC).
In Single-Page Applications (SPAs) lädt der Browser einmal eine minimale HTML-Struktur; die Navigation erfolgt danach client-seitig, ohne vollständige Seiten-Reloads. SPAs ermöglichen reichhaltige Interaktionen, haben aber oft schwere Initial-Ladezeiten und SEO-Herausforderungen. Deshalb ist es wichtig, die richtige Rendering-Strategie (SSR, SSG oder RSC) passend einzusetzen.
Zusammenfassung:
| Strategie | Beschreibung | Vorteile | Nachteile | Typische Use-Cases |
|---|---|---|---|---|
| CSR – Client-Side Rendering | Rendering passiert im Browser. Der Server liefert hauptsächlich HTML-Skelett & JS. | – Interaktive Seiten möglich – Schnelle Navigation nach erstem Laden | – Längere Time-to-Interactive – SEO schwieriger | Single-Page Applications (SPA), z.B. React-Apps |
| SSG – Static Site Generation | HTML wird beim Build generiert. Server liefert fertige Seiten. | – Sehr schnelle Auslieferung- Geringe Serverkosten- SEO-freundlich | – Inhalte nicht dynamisch – Rebuild nötig bei Änderungen | Landingpages, Dokumentationen, Blogs |
| SSR – Server-Side Rendering | HTML wird auf dem Server generiert und an den Client geschickt. | – Schnellere First-Contentful-Paint (FCP) – Bessere SEO | – Serverlast höher – Interaktivität erfordert zusätzlich JS | News-Seiten, Blogs, E-Commerce |
| RSC – React Server Components | Komponenten werden auf dem Server gerendert, nur das Nötige an den Client geschickt. | – Kleinere JS-Bundles- Schnelle Ladezeiten- Dynamische Inhalte ohne komplette CSR | – Komplexere Architektur – Noch nicht überall etabliert | Moderne React-Apps, wo Performance & Server-Interaktion wichtig sind |
Client-Side Rendering (CSR):
Alles Rendering passiert im Browser.
CSR wurde populär, als Verbrauchercomputer leistungsfähig genug waren und zuverlässige Internetverbindungen verfügbar wurden. Die Anwendung wird einmal gebaut, auf einem statischen Server bereitgestellt – und fertig.
Ablauf: Browser lädt minimales HTML + komplettes JS-Bundle.
Vorteile: Einfaches Hosting, schnelle Builds, reichhaltige Interaktionen.
Nachteile: Langsamer erster Seitenaufbau auf schwachen Geräten, SEO hängt von JS-fähigen Crawlern ab.
Static-Side Generation (SSG):
Vor der Bereitstellung wird ein Build-Prozess ausgeführt. Dabei werden die Daten abgerufen und das HTML vorab gerendert, sodass die HTML-Dateien bereits alle benötigten Daten enthalten.
Ablauf: Build-Tool führt die Anwendung vorab aus → erzeugt statisches HTML + Assets → CDN liefert sofort.
Vorteile: Nahezu null TTFB dank Edge-Caches, hervorragende SEO, keine Serverkosten für Abrufe.
Nachteile: Inhalte aktualisieren sich nur beim Neubuild oder via ISR (Incremental Static Regeneration).
Server-Side Rendering (SSR):
Bei jedem Request an den Server findet der Großteil der Datenverarbeitung und des Renderings auf dem Server statt. Das HTML wird dann an den Browser geschickt, während das JS-Bundle heruntergeladen wird, um Interaktivität hinzuzufügen (z. B. Events).
Ablauf: Request trifft auf den App-Server → Server sendet Markup an den Browser → Browser beginnt mit dem Rendern, während JS lädt → Events und Interaktivität werden hinzugefügt (Hydration)
Vorteile: Frische, personalisierte Daten bei jedem Request; hervorragende SEO; geringere Bundle-Größe, da vieles serverseitig passiert.
Nachteile: Erfordert Server-Runtime; höhere Infrastrukturkosten bei Last; das komplette Client-Bundle wird trotzdem ausgeliefert.
React-Server Components (RSC):
Konventionen und Standards werden gerade erst entwickelt und übernommen.
Server Components laufen auf dem Webserver während eines Page-Requests, sodass du direkt auf deine Datenebene zugreifen kannst, ohne eine API zu bauen. Sie werden gerendert, bevor deine Anwendung gebündelt wird, und können Daten und JSX als Props an Client Components weitergeben.
HTML + Komponentenbaum werden aufgeteilt:
nicht-interaktive Teile bleiben auf dem Server.
Ablauf: Browser fordert Seite an → Server rendert RSC-Payload (JSON) + Shell-HTML → Browser fügt Markup zusammen → nur Client Components werden hydriert.
Vorteile: Kein JS für rein serverseitige Komponenten → Bundle-Größe drastisch reduziert; einfaches Daten-Fetching nah an der Datenbank; Interaktivität bleibt über „Client-Islands“ möglich.
Nachteile: Derzeit framework-abhängig (Next.js 15, Remix 3); neues mentales Modell; erfordert Server-Hosting.
