Hauptbereich
Agency
web-development

Render-Strategien für schnelle Websites

Redaktion ·

Render-Strategien für schnelle Websites

Wie und wo eine Seite ihr HTML erzeugt, entscheidet maßgeblich darüber, wie schnell sie lädt und wie aufwendig sie zu betreiben ist. Es gibt dafür mehrere Render-Strategien, und keine ist universell „die beste” — jede hat ein klares Stärkenprofil. Dieser Artikel betrachtet sie aus der Entwicklungs- und Performance-Perspektive: Was bedeutet jede Strategie für TTFB und LCP, für Wartbarkeit und Kosten — und wann passt welche? Die SEO- und Crawlbarkeits-Sicht auf dieselben Begriffe behandelt der Artikel SSR, CSR, SSG und Hydration.

Static Rendering / Prerendering

Beim statischen Rendern wird das HTML vorab beim Build erzeugt — eine fertige Datei pro URL. Bei einer Anfrage liefert der Server (oder ein CDN) diese Datei direkt aus, ohne etwas zu berechnen.

  • TTFB: Bestmöglich und konstant — es gibt nichts zu rendern, nur auszuliefern.
  • LCP/FCP: Sehr schnell, das HTML ist sofort da.
  • Interaktivität: Niedrige Blockierzeit, solange wenig JavaScript dazukommt.
  • Wartbarkeit/Kosten: Günstig und robust; der Haken ist, dass sich Inhalte erst beim nächsten Build ändern.

Ideal für Inhalte, die sich selten ändern und vorhersehbare URLs haben — also klassische Marketing-Sites, Blogs, Dokumentation.

Server-Side Rendering (SSR)

Bei SSR erzeugt der Server das HTML pro Anfrage frisch. Jeder Aufruf läuft durch die Render-Logik, bevor die Antwort zurückgeht.

  • TTFB: Hängt von der Serverlast und der Datenbeschaffung ab — potenziell langsamer als statisch, weil pro Request gerechnet wird.
  • LCP/FCP: In der Regel schnell, weil keine zusätzlichen Client-Roundtrips fürs Datenladen nötig sind.
  • Interaktivität: Oft gut, weil der Main-Thread während des Ladens weniger blockiert wird.
  • Wartbarkeit/Kosten: Höhere Rechenkosten und mehr Server-Infrastruktur.

Passt überall, wo Inhalte personalisiert oder live sind — Dashboards, eingeloggte Bereiche, Echtzeit-Daten.

ISR / On-Demand-Revalidation

Incremental Static Regeneration (ISR) verbindet beide Welten: Seiten werden statisch ausgeliefert, aber im Hintergrund nach Ablauf einer Frist oder auf Anforderung neu gebaut. Der Nutzer bekommt das schnelle statische HTML, und der Inhalt bleibt trotzdem aktuell — ohne kompletten Rebuild der ganzen Site.

  • TTFB: Statisch-schnell für die ausgelieferte Version.
  • Aktualität: Konfigurierbar — von „minutengenau” bis „nur bei Änderung neu bauen”.
  • Wartbarkeit/Kosten: Günstiger als reines SSR bei großen Seitenmengen, aber komplexer im Cache-Verhalten.

Die ideale Wahl für große Sites mit vielen Seiten, die sich gelegentlich ändern — Shops mit vielen Produkten, große Content-Portale.

Edge-Rendering

Edge-Rendering verschiebt die Berechnung näher zum Nutzer — auf verteilte Knoten in einem CDN statt in ein einzelnes zentrales Rechenzentrum. Es ist keine eigene Render-Art, sondern ein Ort: SSR oder Revalidation läuft am Edge.

  • TTFB: Deutlich niedriger, weil die physische Distanz zum Nutzer schrumpft.
  • Einschränkung: Edge-Laufzeiten sind leichtgewichtig; nicht jede Server-Logik (große Abhängigkeiten, lange Datenbankzugriffe) läuft dort gut.

Sinnvoll für global verteilte Nutzer und Logik, die schnell und nah am Nutzer entscheiden muss — Geo-Personalisierung, A/B-Weichen, einfache SSR.

Hydration — wenn statisches HTML interaktiv wird

Egal welche Server-Strategie: Soll die Seite im Browser interaktiv sein, muss das ausgelieferte HTML mit JavaScript „zum Leben erweckt” werden. Dieser Schritt heißt Hydration.

Gegenmittel sind partielle oder progressive Hydration und die Islands-Architektur: nur die Teile hydrieren, die wirklich interaktiv sein müssen, statt der ganzen Seite. web.dev empfiehlt explizit, statisches Rendern oder SSR einem vollen Rehydration-Ansatz vorzuziehen.

Welche Strategie wann?

  • Marketing-Site / Blog: Static (Prerendering). Schnell, billig, robust.
  • Große Content- oder Shop-Site mit vielen Seiten: ISR / On-Demand-Revalidation. Statische Geschwindigkeit plus geregelte Aktualität.
  • App mit Login / Live-Daten: SSR, gern am Edge für niedrigeren TTFB.
  • Global verteilte Nutzer: Edge-Rendering als Ort für SSR/Revalidation.
  • Immer: Hydration sparsam einsetzen — nur dort, wo Interaktivität wirklich gebraucht wird.

Die Grundregel: So statisch wie möglich, so dynamisch wie nötig. Wer den Aktualitätsbedarf ehrlich einschätzt, vermeidet teures SSR an Stellen, wo statisches HTML längst reichen würde.

FAQ

Was ist der Unterschied zu dem SSR/CSR/SSG-Artikel? Dieser Artikel betrachtet Render-Strategien aus der Dev- und Performance-Sicht: TTFB, LCP, Wartbarkeit, Kosten und die Wahl nach Anwendungsfall. Der andere Artikel behandelt dieselben Strategien unter SEO- und Crawlbarkeits-Aspekten.

Welche Strategie ist am schnellsten? Static Rendering. Das HTML wird vorab gebaut und nur ausgeliefert, der TTFB ist konstant niedrig. Der Preis ist, dass Inhalte erst beim nächsten Build oder bei Revalidation aktuell werden.

Wann lohnt sich SSR statt statisch? Wenn Inhalte personalisiert oder live sind — eingeloggte Bereiche, Echtzeit-Daten, nutzerspezifische Ansichten. Für unveränderliche Inhalte ist SSR meist teurer und langsamer als nötig.

Was bringt Edge-Rendering? Es verschiebt die Berechnung näher zum Nutzer und senkt damit den TTFB. Edge-Laufzeiten sind aber leichtgewichtig — schwere Logik mit großen Abhängigkeiten gehört nicht zwingend dorthin.

Warum ist Hydration ein Performance-Risiko? Weil sie Main-Thread-Zeit kostet: Die Seite sieht geladen aus, reagiert aber erst, wenn das JavaScript ausgeführt ist. Das verschlechtert TBT und INP. Lösung: partielle Hydration oder Islands — nur interaktive Teile hydrieren.

Themenuebersicht

Web DevelopmentPerformance