Server-Side-Rendering (SSR) ist eine Technik zum Rendern einer normalen clientseitigen Anwendung auf dem Server und zum Senden einer vollständig gerenderten Seite als Antwort an den Client. Das führt zu einer Verbesserung der UX, da der Inhalt schneller angezeigt wird und genügend Zeit zum Laden der gesamten Frontend-App bleibt.

Das ist aber nicht das Wichtigste, das man mit SSR bekommt. Der Hauptzweck besteht darin, Web-Crawlern crawlbare Inhalte zur Verfügung zu stellen und damit die Suchmaschinenoptimierung (SEO) zu verbessern.

Bei regulären Client-Side-Rendering (CSR)-Anwendungen, die Angular verwenden, wird Text im HTML durch JavaScript eingefügt. Für die meisten Crawler liefert das keine Informationen, da sie in der Regel reguläres HTML (Seitenquelle) parsen und der Inhalt dort nicht vorhanden ist. Der Crawler von Google ist jedoch in der Lage, JavaScript zu parsen. Selbst wenn man sich nicht um die anderen Crawler kümmert, wird dadurch die Notwendigkeit von SSR nicht aufgehoben. Das Teilen von Content in sozialen Medien ist wichtig, und Vorschauseiten funktionieren ohne SSR einfach nicht mehr.

In diesem Blogbeitrag konzentrieren wir uns darauf, den Hauptunterschied zwischen zwei Arten von SSR zu erklären: dynamisch und statisch. Nach ein wenig Theorie erklären wir die Unterschiede in einer Schritt-für-Schritt-Anleitung.

Dynamic SSR

Dieses Konzept erfordert die Verwendung eines Live-Node.js-Servers, der SSR-Inhalte generiert und bereitstellt. Eine reguläre Angular-CSR-App wird normalerweise als statisches js-Bündel von einem Webserver oder CDN bereitgestellt. Bei dynamischem SSR für mehrere Seiten, muss sie den Request an den Node.js-Server für die SSR-Seiten weiterleiten. Jedes Mal, wenn der Node.js-Server einen Request erhält, führt er die Angular-App auf dem Node.js-Server aus und gibt das resultierende HTML an den Browser zurück.

Das wirkt sich auf die Leistung (im Vergleich zum statischen Pre-Rendering) aus, da der Node.js die App bei jeder Request rendern muss. Das kann durch Zwischenspeichern der Requests verbessert werden. Die Implementierung einer Cache-Lösung mit SSR erfordert jedoch einen gewissen Aufwand ( Schritt-für-Schritt-Anleitung ).

Wann eignet sich das?

• Die App ist sehr dynamisch.
• Es gibt Live-Daten, die sofort dargestellt werden müssen.
• Der Inhalt der App wird auf der Grundlage externer Quellen gerendert, z.B. einem CMS, wo sich jederzeit alles ändern kann.

Static Pre-Rendering

Wie der Name schon sagt, nutzt dieser Ansatz eine vorgefertigte Version der App, um die Vorteile von SSR zu nutzen. Sie (oder Ihr CI-System) generieren die vorgerenderte Seite mit einem einfachen Angular-CLI-Befehl. Mit diesem Ansatz kann die Angular-App auf jedem Server, der statische Dateien bedient, eingesetzt werden.

Hier warten wir nicht darauf, dass Node.js die Anfrage verarbeitet, um eine bessere Leistung zu erzielen. Dieser Ansatz eignet sich für inhaltsreiche Seiten, bei denen der Pre-Rendering-Befehl leicht bei jeder Änderung ausgelöst werden kann. Nicht vergessen: Wann immer Änderungen gebraucht werden, muss das Build-Skript erneut ausgeführt und der Inhalt des Ordners dist/ veröffentlicht werden.

Wann macht es Sinn?

• Die Anwendung oder die Routes die pregerendet werden, sind statisch (z.B. home.html, about.html, contact.html, etc).
• Die Anwendung wird nicht so oft aktualisiert, und wenn dies der Fall ist, kann der Pre-Render-Befehl ausgeführt werden.

Demo

Diese Demo zeigt die wichtigsten Unterschiede zwischen den beiden Ansätzen. Um zu beginnen, klont das Repo von github und folgt dem Beispiel. Ist das erledigt, startet ihr das Projekt mit ./cli/startproject.sh . Dieses Script startet zwei verschiedene Setups. Eines für das Dynamic-SSR unter http://localhost:8090 und das andere für das Static-Pre-Rendering unter http://localhost:8080 .

Navigiert zu http://localhost:8090/public und beachtet, wie sich der Text links unten schnell von Rendered by Server zu Rendered by Browser ändert.

Öffnet jetzt einen neuen Tab und navigiert zu http://localhost:8080/prerender (achtet darauf, Port 8080 anzugeben). Hier findet der gleiche Textwechsel statt. Geht schließlich zu http://localhost:8090/browser , wo nur der Text Rendered by Browser angezeigt wird. Das bedeutet, dass diese Route nicht serverseitig gerendert wird.

Um mit dem Tutorial fortfahren zu können, müsst ihr JavaScript in eurem bevorzugten Browser deaktivieren. Auf Chrome geht das in der Entwicklerkonsole. Hier muss man das "Run Command" ( explanation ) öffnen und "Javascript deaktivieren" eingeben. Ihr könnt es mit der gleichen Prozedur wieder aktivieren und "Javascript aktivieren" eintippen.

In Mozilla Firefox funktioniert es, indem ihr in die Entwicklerkonsole geht und dann in die "Einstellungen". Dieser Vorgang sollte auch bei allen anderen Browsern ähnlich ablaufen. Wichtig: Tut das für jeden Reiter, den ihr in diesem Tutorial geöffnet habt.

Wenn das erledigt ist, prüft http://localhost:8090/browser . Es sollte leer sein, da diese Seite kein SSR verwendet und wir gerade JavaScript deaktiviert haben. Geht nun zurück zu den Tabs http://localhost:8090/public und http://localhost:8080/prerender . Dort seht Ihr immer noch den Inhalt und die Nachricht Rendered by Server .

Um den Unterschied zwischen Dynamic-SSR und Static Pre-Rendering zu zeigen, müsst ihr für beide Seiten mehrere Seitenaktualisierungen (F5) durchführen. Stellt sicher, dass JavaScript für beide deaktiviert ist. Überprüft nun die aktuelle Uhrzeit für beide. Ihr werdet sehen, dass http://localhost:8080/prerender immer die gleiche Zeit hat. Das liegt daran, dass dieser Inhalt bei der Erstellung der App generiert wurde. Umgekehrt erzeugt http://localhost:8090/public bei jeder Anfrage neue Versionen, so dass sich der Zeitstempel jedes Mal ändert.

Fazit

Bei der Wahl von SSR solltet ihr euch für einen der beiden bestehenden Ansätze entscheiden: Dynamic SSR oder Static Pre-Rendering. Je nachdem, ob die App-Inhalte eher statisch oder dynamisch sind, solltet ihr euch für einen der beiden Ansätze entscheiden.

Für die meisten Seiten, die statische Seiten wie "Über uns", "Kontakt" oder Landing Pages haben, reicht Pre-Rendering ausreichen. Wenn euch eine Schritt-für-Schritt-Anleitung zur Implementierung von dynamischem SSR interessiert, lest unseren Blogpost dazu .

Braucht ihr mehr Hilfe oder Input, wie man Server Side Rendering auf der eigenen Website oder App wählt und implementiert?

Get in touch