Wie unterscheidet sich die Performance von Client-side Rendering (CSR), Server-side Rendering (SSR) und Static Site Generation (SSG) hinsichtlich der Core Web Vitals?

Die Performance-Auswirkungen von CSR, SSR und SSG auf die Core Web Vitals hängen primär davon ab, an welchem Punkt der Request-Pipeline das HTML generiert wird.

Bei Client-side Rendering (CSR) erhält der Browser zunächst ein fast leeres HTML-Dokument. Die Generierung der Benutzeroberfläche erfolgt erst nach dem Download und der Ausführung des JavaScript-Bundles. Dies führt zu einem verzögerten Largest Contentful Paint (LCP), da der Hauptinhalt erst spät gerendert wird. Zudem ist das Risiko für Cumulative Layout Shift (CLS) hoch, wenn Inhalte asynchron nachgeladen werden und bestehende Elemente verschieben.

Server-side Rendering (SSR) verschiebt die HTML-Erstellung auf den Server. Der Browser empfängt ein vollständig gerendertes Dokument, was den LCP massiv verbessert. Die Herausforderung liegt hier beim First Input Delay (FID) bzw. dem Interaction to Next Paint (INP). Obwohl die Seite visuell vorhanden ist, bleibt sie oft für einige Sekunden nicht interaktiv, bis das JavaScript-Bundle geladen und die sogenannte Hydration abgeschlossen ist.

Static Site Generation (SSG) bietet die beste Performance für den LCP, da die Seiten bereits während des Build-Prozesses erstellt und über ein Content Delivery Network (CDN) ausgeliefert werden. Die Antwortzeiten sind minimal, da keine serverseitige Berechnung pro Request erfolgt. Wie bei SSR ist die Hydration der kritische Pfad für die Interaktivität.

Besonders bei performanzkritischen E-Commerce Plattformen entscheiden diese Unterschiede über die Conversion-Rate und das SEO-Ranking.

Wir empfehlen für inhaltsgetriebene Seiten konsequent den Einsatz von SSG in Kombination mit Incremental Static Regeneration (ISR). Für hochdynamische Anwendungen ist SSR die technisch überlegene Wahl gegenüber CSR, um die Sichtbarkeit und Indexierung zu sichern. CSR sollte ausschließlich in geschlossenen App-Umgebungen wie Dashboards eingesetzt werden, in denen die initiale Ladezeit gegenüber der App-ähnlichen Interaktion nach dem ersten Laden zweitrangig ist.