Server-Side Rendering in Angular – Booste deine User Experience

Click here for the english version of this blog post.

Server-Side Rendering (SSR) in Angular 21: Schnellere Ladezeiten und besseres Nutzererlebnis

Mit Angular v21 sind Server-Side Rendering (SSR), Hydration und zoneless Change Detection fester Bestandteil des Standard-Stacks geworden und rücken damit noch stärker in den Fokus moderner Angular-Anwendungen. Wenn Du wissen willst, was Server Side Rendering in Angular bedeutet, warum es sinnvoll ist und welche Möglichkeiten Dir die aktuellen Angular-Versionen (ab v19 bis v21) rund um SSR, Prerendering und Hybrid Rendering bieten, bist Du hier genau richtig.

Dieser Artikel ist Teil des Angular Guides, in dem wir aktuelle Features und wichtige Architekturthemen behandeln.

Was ist SSR in Angular und was bringt es uns?

Standartmäßig werden Angular-Apps im Browser geladen, d. h. der Client lädt die Anwendung, das JavaScript wird ausgeführt und erst dann wird die UI aufgebaut. Das kann bei großen Apps oder langsamer Verbindung die erste Darstellung verzögern.
Server-Side Rendering setzt genau hier an. Die Anwendung oder Teile davon werden bereits auf dem Server gerendert und als fertiges HTML an den Client geschickt. Der Browser erhält also direkt sichtbare Inhalte, noch bevor das JavaScript vollständig geladen und ausgeführt wurde. Danach übernimmt Angular wie gewohnt die Steuerung.

Folgende Vorteile bekommen wir dadurch:

• Schneller sichtbare Inhalte: Selbst bei großen Anwendungen sieht der Benutzer sehr schnell nach dem initialen Laden etwas auf dem Bildschirm.

• Besseres Nutzererlebnis bei langsamen Verbindungen: Gerade auf mobilen Geräten kann SSR helfen, die wahrgenommene Ladezeit zu reduzieren, da der Benutzer Inhalte schon sieht und nicht bemerkt, dass Angular im Hintergrund noch am Laden ist.

• Bessere Ausgangslage für SEO & Social Media: Indexierung, Link-Vorschauen und Performance-Rankings funktionieren deutlich besser, da beim initialen Laden der Seite sofort fertiges HTML vorhanden ist.

• Grundlage für moderne Hybrid-Strategien: SSR lässt sich in Angular gezielt mit reinem Client-Rendering und Prerendering (SSG) kombinieren, je nach Route und Anwendungsfall kann individuell gesteuert werden.

Was ist der aktuelle Stand in Angular v21?

In der Release-Ankündigung von Angular v19 wurden vor allem drei Bereiche rund um SSR hervorgehoben: Route-Level Render Modes, Incremental Hydration und die Arbeit an einem zoneless Rendering-Ansatz. Seitdem wurden diese Funktionen mit Angular 20 und 21 weiter ausgebaut und sind heute ein zentraler Bestandteil des offiziellen Hybrid-Rendering-Modells.

Die wichtigsten Neuerungen und Weiterentwicklungen im Überblick:

• Route-Level Render Mode / Hybrid Rendering: Seit Angular 19 bestimmt Du mit dem ServerRoute-Interface für jede Route, ob sie der Server rendert (SSR), der Build-Prozess prerendert oder der Client rendert (CSR).

• Incremental Hydration: Bereits in Angular 19 als Developer Preview eingeführt, erlaubt sie das schrittweise Hydrieren einzelner Template-Bereiche basierend auf Triggern wie “on viewport” oder “on interaction”. In den nachfolgenden Versionen wurde dies, basierend auf den Deferrable Views (@defer), stable.

• Zoneless Angular: Mit Angular 20 und 21 hat das Entwicklerteam die Unterstützung dafür, Angular ohne zone.js zu nutzen deutlich vorangetrieben. In Angular 21 ist Zoneless Change Detection für neue Projekte der Standard, was auch für SSR-Szenarien eine bessere Performance-Basis und klarere Change-Detection-Semantik schafft.

Wie nutze ich Server-Side Rendering in meiner Angular Anwendung?

Mit der Angular CLI hast du zwei Möglichkeiten SSR in deiner Anwendung zu aktivieren. Wenn du mit ng new ein neues Angular Projekt aufsetzt, wirst du direkt gefragt, ob du Server-Side Redering nutzen möchtest. Natürlich gibt es aber auch einen Befehl mit dem du SSR in deiner bestehenden Anwendung nachrüsten kannst: ng add @angular/ssr

Dadurch bekommst du vier neue Dateien:

• server.ts: Angular liefert dir hier einen vollwertigen kleinen Node.js-Webserver, basierend auf Express. Wenn ein Nutzer deine Seite aufruft, nimmt dieser Server die Anfrage entgegen, startet Angular im Hintergrund, lässt die Seite rendern und schickt das fertige HTML zurück an den Browser.
• src/main.server.ts: So wie die main.ts der Startpunkt für deine App ist, ist diese Datei das exakte Gegenstück dazu für den Server. Sie sagt dem Node-Server, wie er deine Angular-App starten soll.
• src/app/app.config.server.ts: Hier kannst du Konfigurationen und Provider festlegen, die nur den Server betreffen.
• src/app/app.routes.server.ts: Diese Datei ist für das Server-Routing zuständig. Hier legst du fest, welche Seiten deiner Anwendung Server-Side oder Client-Side gerendert werden.

Render Modes auf Route-Level: Gezielte Kontrolle über SSR, Prerendering und Client-Side Rendering

Standardmäßig rendert Angular bei aktivierter Server-Side Rendering Unterstützung alle Routen mit Parametern auf dem Server und prerendert statische Routen ohne Parameter. In Angular v21 ist dieser Prozess deutlich flexibler. Mit den sogenannten Route-Level Render Modes legst Du selbst fest, ob Angular eine Route auf dem Server, im Client oder bereits beim Build rendert.

In unserem Beispiel hat unsere Anwendung drei Seiten, für die wir in der app.routes.server.ts jeweils einen anderen Render Mode festgelegt haben:

• Die About Page wird clientseitig gerendert (CSR), d. h. erst nachdem der Browser das Javascript geladen hat, baut Angular die Seite im Browser auf → RenderMode.Client
• Das Impressum wird prerendert, was bedeutet, dass Angular die Seite genau einmal beim Build der App rendert und sie in eine statische HTML-Datei verwandelt. Deshalb spricht man hier oft auch von Static Site Generation (SSG) → RenderMode.Prerender
• Alle anderen Seiten, in unserem Fall die Product Page, werden serverseitig gerendert (SSR). Hier wird jedes Mal, wenn die Route aufgerufen wird, die Componente neu auf dem Server gerendert und das fertige HTML an den Browser geschickt → RenderMode.Server

Den Unterschied zwischen CSR und SSR können wir uns auch direkt anschauen, indem wir den Seitenquelltext der About Page und der Product Page vergleichen. Den Seitenquelltext deiner Angular Anwendung kannst du im Browser mit STR + U oder per Rechtklick im Kontextmenü öffnen.

Das ist der Seitenquelltext der About Page. Hier sehen wir, dass im body nur <app-root></app-root> steht und im Quelltext kein HTML vorhanden ist. Alles was wir in der About Page sehen, wird erst nach dem Laden des Javascript im Browser gerendert.

Im Gegensatz dazu, können wir beim Seitenquelltext der Product Page durchaus HTML und auch CSS sehen: <h1>Angular SSR Demo</h1>. Hier hat das Rendern der Server übernommen und der Browser kann sofort den Inhalt der Product Page anzeigen, ohne auf das Laden der Javascript-Datei zu warten.

Was ist Hydration?

Hydration bezeichnet den Prozess, bei dem Angular seine interne Logik und Event-Listener mit dem bereits sichtbaren, vom Server generierten HTML verknüpft. Dabei wird zuerst die DOM-Struktur mit den Angular Komponenten zusammengeführt und danach die Event-Handler registriert. Das heißt aber auch, dass es ein Zeitfenster gibt, indem der Benutzer die UI schon sehen kann, aber damit noch keine Logik verbunden ist. Meist sind das nur Millisekunden, aber bei einer schlechten Internetverbindung können es auch Sekunden werden.

Natürlich gibt uns Angular hier aber auch ein Hilfsmittel an die Hand: withEventReplay().
Das ist eine Funktion die wir in der app.config.ts beim Konfigurieren der Hydration angeben können.

Damit fängt Angular alle Interaktionen des Benutzers ab und packt sie in eine Art Warteschlange. Ist das Javascript fertig geladen, werden automatisch nacheinander alle Interaktionen ausgeführt. Somit gehen keine Interaktionen verloren.

Mehr Informationen zu Hydration findest du in der Angular Dokumentation.

Incremental Hydration: Optimierte Ladezeiten durch kontrollierte Komponenten-Hydration

Incremental Hydration, seit Angular 19 als Developer Preview eingeführt, löst ein zentrales SSR-Problem: Bei normaler Full-App-Hydration wird die gesamte serverseitig gerenderte Seite sofort mit JavaScript interaktiv gemacht. Dies betrifft auch Bereiche, die der Nutzer gar nicht sofort braucht. Das führt zu unnötig großen initialen Bundles, längeren Ladezeiten und blockiert den Browser – was sich negativ auf Core Web Vitals wie INP (Interaction to Next Paint) und TBT (Total Blocking Time) auswirkt. Incremental Hydration hydriert nur die benötigten Teile zur richtigen Zeit, während der Rest statisch bleibt und über Event Replay später nachgeholt wird.

Damit wir Incremental Hydration nutzen können, tauschen wir in der app.config.ts withEventReplay() mit withIncrementalHydration() aus. Da Incremental Hydration auf dem Event Replay aufbaut, werden auch weiterhin alle Interaktionen des Benutzers abgefangen.

Wie benutzt man Incremental Hydration?

Nachdem wir Angular gesagt haben, dass wir Incremental Hydration verwenden wollen, können wir in unserer Product Page jetzt Deferrable Views verwenden, um spezifisch anzugeben, wann welche Teile unserer UI hydriert werden sollen. Hier findest du mehr Informationen zu Deferrable Views.

Innerhalb von @defer-Blöcken definierst Du mit hydrate den Zeitpunkt, wann Angular den Inhalt hydrieren soll:

• hydrate on: Hiermit kannst du auf verschiedene vordefinierte Trigger zugreifen. Es gibt z.B.
  • viewport – triggert, wenn der Content auf dem Screen sichtbar wird
  • interaction – triggert, wenn der Benutzer mit dem Content interagiert
  • hover – triggert, wenn der Benutzer über dem Content hovered
• hydrate when: Das lässt dich einen eigenen Trigger definieren, bei welcher Bedingung der Inhalt hydriert werden soll
• hydrate never : Damit kannst du die Hydration komplett ausschalten. Der Inhalt ist beim initial Load statisch.

Wichtig: Hydration optimiert nur den Initial Load der Anwendung, d. h. die hydrate-Trigger greifen nur, wenn die Seite das erste Mal geladen wird.

Du kannst die hydrate-Trigger aber auch mit den regulären Triggern der Deferrable Views kombinieren:

In unserem Beispiel verwendet Angular beim Initial Load der Seite hydrate on interaction. Bei jedem nachfolgenden Laden bzw. Render der Seite durch den Client wird on idle angewendet. Beispielsweise wenn det Benutzer auf einen Router-Link klickt, der eine Seite mit dieser Komponente lädt.

Weitere vordefinierte Trigger und Informationen zu Incremental Hydration findest du in der offiziellen Dokumentation.

Erfahrung ist der beste Lehrer: Hands-On für SSR

Bist Du bereit, die Theorie in die Praxis umzusetzen? Alle Beispiele die wir im Artikel gezeigt und besprochen haben, sind interaktiv in unserem Stackblitz vorhanden.

Mit welchen Themen geht es weiter?

Ein weiteres Hot Topic von Angular aind aktuell die Signal Forms! Einen ersten Artikel haben wir dazu schon veröffentlicht: Signal Forms – Schnell reaktive Formulare in Angular
Dieser bietet einen Einstieg und Überblick zu den Signal Forms und ihrer Verwendung und was sie so bahnbrechend machen.

Auch in den nächsten Artikeln wird es um die Signal Forms gehen, wo wir bestimmte Themen noch genauer betrachten werden.

Terminübersicht der nächsten Angular Schulungen

Related posts:

Server-Side Rendering in Angular – Boost Your User Experience [Aktuell mit v21] Angular Guide – Überblick zu allen Signal Themen und Hot Topics [Latest in v21] Angular Guide – Overview of all Signal topics and other highlights Reactive APIs in Angular Teil 1 – Resource API resource() und rxResource()