Sie sind hier

Server-Side-Pre-Rendering (SSPR)

Eintrag zuletzt aktualisiert am: 12.01.2023
 Fachbücher zum Thema Server-Side-Pre-Rendering (SSPR)

Beim Server-Side-Pre-Rendering (SSPR) wird zunächst auf dem Webserver eine statische HTML-Seite gerendert, die dann mit JavaScript- oder WebAssembly-Code hydriert wird und danach eine dynamische Seite mit Client-Side-Rendering (CSR) darstellt.

Details

Server-Side-Pre-Rendering ist eine Funktion in einigen modernen JavaScript-basierten Webframeworks, die eigentlich auf dem Client (Client-Side-Rendering - CSR) rendern, dieselben Komponenten/Templates auch auf einem Webserver auszuführen. Der Webserver, der die Single-Page-Web-App ausliefert, muss dazu node.js unterstützen, um das JavaScript-basierte Webframework auf dem Server ausführen zu können.

Der Webbrowser erhält dann HTML vom Server, das zunächst statisch ist, dann aber "hydriert" wird. Als "Hydrieren" bezeichnet man das Anreichern einer statischen Webanwendung um JavaScript-Code, sodass die Webanwendung dann im Browser interaktiv wird.

Dieses Server Side Pre-Rendering wird oft auch einfach als Server Side Rendering (SSR) bezeichnet. Das Weglassen des "Pre" stellt aber einen Begriffskonflikt mit Techniken dar, die ausschließlich auf dem Server rendern, z.B. PHP, Java Server Pages und ASP.NET Core. Eine Webanwendung, die sowohl auf dem Webserver als auch im Webbrowser läuft, wird auch als "isomorphisch" oder "universal" bezeichnet. In Angular heißt die entsprechende Technik daher auch Angular Universal [https://angular.io/guide/universal].

Verwirrenderweise wird Server Side Pre-Rendering gelegentlich auch mit Static Site Generation (SSG) gleichgesetzt (z.B. in [https://vite-plugin-ssr.com/pre-rendering]). Bei der Static Site Generation vollzieht sich das komplette Rendering aller Seiten zur Entwicklungszeit. Die Seite ist danach nicht interaktiv im Browser.

Was bringt Server Side Pre-Rendering?

Bei einer Single-Page-Web-App, die im Browser rendert, kann es einen Moment dauern, bis der Benutzer die erste angesprungene Seite sieht, denn der gesamte JavaScript-Code, sowohl der selbstgeschriebene als auch der notwendige Web-Framework-Code, muss in den Browser geladen werden, bevor das Rendering beginnen kann. Web-Frameworks nutzen daher typischerweise Bundling und Minifikation, um diese Zeit bis zur Darstellung des Inhalts (engl. Time to Content) zu beschleunigen. Server Side Pre-Rendering kann die Time to Content weiter reduzieren, denn der Benutzer sieht bereits eine Inhaltsseite, auch wenn die JavaScript-Dateien noch nicht vollständig geladen sind.

Der zweite große Vorteil von Server Side Pre-Rendering ist die bessere Suchmaschinenoptimierung (Search Engine Optimization – SEO), denn die Crawler der Suchmaschinen erhalten die vorgerenderte Seite vom Webserver.

Nachteile von Server Side Pre-Rendering sind:
  • Nicht alle JavaScript-basierten Webframeworks unterstützen Server Side Pre-Rendering.
  • Der Webserver, der die Single-Page-Web-App ausliefert, muss node.js unterstützen, um das JavaScript-basierte Webframework auf dem Server ausführen zu können. Ein statischer Webserver, der normalerweise bei einer Single-Page-Web-App reicht, funktioniert beim Server Side Pre-Rendering nicht.
  • Der Webserver hat mehr Rechenlast beim Server Side Pre-Rendering als wenn er nur statische Dateien ausliefern muss.
  • Der Aufwand für die Einrichtung der Anwendung ist größer.
  • Es gibt einige Funktionen (z.B. Zugriff auf Browser-APIs), die nicht im Rahmen des Server Side Pre-Rendering möglich sind.