Web Rendering: SSR, CSR, SSG, ISR und Edge erklärt

Was ist Web Rendering?

Web Rendering ist der Vorgang, bei dem aus Anwendungscode und Daten das HTML entsteht, das der Browser anzeigt. Entscheidend ist, wo und wann das passiert: auf dem Server bei jeder Anfrage, im Browser nach dem Laden von JavaScript oder vorab beim Build. Diese Wahl bestimmt Geschwindigkeit, SEO, Hosting-Kosten und die Aktualität der Inhalte.

Die wichtigsten Rendering-Strategien

So funktioniert jede Strategie

• SSG: Ein Build-Schritt schreibt pro URL eine HTML-Datei, ein CDN liefert sie aus. Pro Anfrage läuft nichts, das ist günstig und verträgt Lastspitzen gut, Inhalte aktualisieren sich aber erst nach einem neuen Build.
• SSR: Der Server baut das HTML für jede Anfrage. Inhalte sind immer aktuell und können vom Nutzer abhängen, aber jeder Aufruf kostet Serverzeit und verlängert die Time to First Byte.
• CSR: Der Server schickt eine kleine Hülle und ein JavaScript-Bundle, der Browser baut die Seite. Navigation in der App fühlt sich sofort an, die erste Ansicht wartet aber auf Download und Ausführung des Bundles.
• ISR: Statische Seiten, die nach einer festgelegten Zeit oder auf Auslösung im Hintergrund neu erzeugt werden. So bekommen Sie statisches Tempo mit begrenzter Veralterung.
• Edge Rendering: SSR-Code, der an CDN-Standorten statt in einer Origin-Region läuft. Die Latenz sinkt für entfernte Nutzer, dafür schränken Edge-Laufzeiten die nutzbaren APIs und Bibliotheken ein.

Hydration: Wo Server und Client sich treffen

SSR und SSG liefern fertiges HTML, interaktive Teile brauchen aber trotzdem JavaScript. Hydration ist der Schritt, in dem dieses JavaScript an das vorhandene HTML andockt. Bei großen Seiten ist das teuer, weshalb Frameworks partielle Hydration, Streaming und Server Components anbieten, um weniger JavaScript auszuliefern.

Beispiel: Strategie pro Seite in einem Onlineshop

• Startseite und Ratgeber: SSG, weil sie für alle identisch sind.
• Produktseiten: ISR, damit eine Preisänderung binnen Minuten erscheint, ohne den ganzen Katalog neu zu bauen.
• Warenkorb und Kasse: CSR oder SSR, weil sie vom Besucher abhängen und nicht ranken müssen.
• Banner je Land: Edge Rendering oder ein kleines Client-Skript.

Häufige Fehler

• CSR für öffentliche Seiten, die ranken sollen, und dann überrascht sein, dass Vorschauen und manche Crawler eine leere Seite sehen.
• SSR für Seiten, die sich nie ändern: mehr Serverkosten und ein langsameres erstes Byte ohne Nutzen.
• Ein riesiges JavaScript-Bundle auf serverseitig gerendertem HTML, sodass die Seite fertig aussieht, aber nicht auf Klicks reagiert.
• Personalisierte SSR-Ausgabe im CDN cachen und die Seite eines Nutzers an einen anderen ausliefern.
• Die Strategie nach Trend wählen, statt echte Seiten zu messen.

Rendering, Performance-Tests und Monitoring

Die Rendering-Strategie zeigt sich direkt in den wichtigen Messwerten. Statische und serverseitig gerenderte Seiten helfen meist beim Largest Contentful Paint, aufwendige Hydration schadet Interaction to Next Paint, und CSR verlagert Arbeit auf das Gerät des Besuchers. Verfolgen Sie die Core Web Vitals regelmäßig, zum Beispiel mit LoadFocus Page Speed Monitoring. Die Einrichtung beschreibt der Beitrag Core Web Vitals mit Alerts und Reports überwachen (auf Englisch).

SSR verändert auch die Kapazitätsplanung: Jede Anfrage führt Code aus. Fahren Sie vor einem Launch einen Lasttest, um zu sehen, ab wann die Antwortzeiten steigen. Eine statisch ausgelieferte Seite testet dagegen vor allem das CDN.

Häufige Fragen: Web Rendering

SSR oder SSG: was sollte ich wählen?

SSG, wenn eine Seite für alle Besucher gleich ist und sich selten ändert. SSR, wenn die Seite von der Anfrage abhängt, etwa von einem Cookie, dem Standort oder aktuellen Daten. Wer beides braucht, regeneriert statische Seiten zeitgesteuert oder auf Abruf (ISR).

Ist Client-Side Rendering schlecht für SEO?

Nicht automatisch. Google kann JavaScript ausführen, braucht dafür aber einen zusätzlichen Schritt, und andere Crawler oder Link-Vorschauen sehen womöglich nur eine leere Hülle. Öffentliche Seiten, die ranken sollen, liefern besser echtes HTML vom Server oder aus dem Build.

Was ist der Unterschied zwischen Rendering und Hydration?

Rendering erzeugt das HTML. Hydration ist der Schritt, in dem JavaScript im Browser an dieses HTML andockt, damit Buttons und Formulare funktionieren. Eine Seite kann komplett gerendert sein und trotzdem erst nach der Hydration auf Klicks reagieren.

Kann ich Rendering-Strategien in einer Website mischen?

Ja. Die meisten modernen Frameworks entscheiden pro Route. Typisch sind statische Marketingseiten, Produktseiten mit ISR und eine eingeloggte App mit Client-Side Rendering.

Welche Rendering-Strategie ist am schnellsten?

Statische Seiten von einem CDN haben meist die niedrigste Time to First Byte, weil pro Anfrage kein Code läuft. Die Geschwindigkeit hängt aber auch von Seitengröße, Bildern und JavaScript ab. Messen Sie Ihre eigenen Seiten, statt dem Etikett zu vertrauen.