Client-, Server-Side-Rendering und Static-Site-Generation im Vergleich

Server-Side-Scripting setzt voraus, dass der Server bei jeder Anfrage vorgeladene HTML-Pages ausliefert. Insbesondere, wenn ein Client fortwährend weitere Anfragen an den Webserver sendet, um dem User neue, veränderte Informationen zukommen zu lassen, bedeutet das eine starke Auslastung der Serverkapazitäten. Für Websites, die eine hohe Zahl an Requests haben oder eine Vielzahl an Nutzerinteraktionen erfordern, eignet sich SSR daher nicht. Bei derartigen Projekten würde die Antwortzeit des Webservers den Vorteil des optimierten Pageloads negieren.

Die bedeutendste Client-Side-Skriptsprache ist JavaScript.

CSR erweist sich insbesondere bei Webprojekten mit einer Menge an Nutzerinteraktionen als gewinnbringender Ansatz. Fällt der initiale Ladeprozess der Website vergleichsweise lang aus, ist das anschließende Rendering weiterer Seiten umso schneller. Die User Experience gestaltet sich deutlich vorteilhafter als beim Server-Side-Rendering, da nicht bei jedem Aufruf einer neuen Seite durch den Nutzer sämtliche Skripte und Inhalte auf einen Schlag und vollständig geladen werden müssen.

Da die Skripte im Browser der Nutzer ausgeführt werden, haben diese – anders als bei Server-Side-Scripts – die Möglichkeit, den Quellcode einzusehen.

Der Fokus auf clientseitige Skripte ist mit zwei entscheidenden Problemen verknüpft: Zum einen ist es für Suchmaschinen schwerer, die Seiten zu erfassen und zu indexieren. Die Crawler von Google sind hierzu zwar in der Lage, doch optimal sind die SEO-Voraussetzungen in diesem Fall nicht – insbesondere, da viele andere Suchmaschinen häufig gar nicht in der Lage sind, clientseitig gerenderte Seiten zu indexieren.

Zum anderen setzt Client-Side-Scripting voraus, dass JavaScript vom Browser unterstützt wird. Dies ist zwar grundsätzlich der Fall – da aber auch Pop-ups und Tracking-Tools auf CSR basieren und die clientseitigen Skripte überdies die Ladezeit beeinflussen, existieren verschiedene Browser-Erweiterungen, die die Skripte blockieren.

Beliebte Static-Site-Generatoren sind z. B. folgende:

• Jekyll
• Hugo
• Pelican
• Middleman
• Expose
• Next
• Gatsby
• Gridsome
• Nuxt
• Hexo
• Eleventy
• Jigsaw
• Vuepress

Static-Site-Generation spielt ihre Stärken insbesondere bei Projekten aus, die viel Content haben, der sich nicht regelmäßig ändert. Typische Beispiele hierfür sind etwa eine persönliche Homepage oder ein Blog, die typischerweise wenig dynamische Inhalte führen und stark von der Top-Geschwindigkeit infolge des Prerenderings (also das Seiten-Vorladen) durch einen Static-Site-Generator profitieren. Zudem bieten SSG-Projekte nur wenig Angriffsflächen, da das Risikopotenzial auf den einzelnen Klick beim Seitenaufruf des Clients beschränkt ist.

Das Prerendering im Rahmen von SSG bringt nicht nur Vorteile mit sich: Der Ansatz erweist sich als äußerst unpraktisch, wenn ein Webprojekt regelmäßigen Änderungen unterworfen ist – ob technischer Natur oder in puncto Content. Für jede Änderung müssen die statischen Seiten des Webprojekts neu „vor“-geladen werden. Je umfangreicher das Projekt ist, desto mehr Zeit nimmt dieser Building-Prozess in Anspruch, weshalb Static-Site-Generation für Websites mit einer Vielzahl an statischen Seiten ungeeignet ist.

Server-Side-Rendering sorgt für einen exzellenten Pageload, der allerdings an eine hohe Auslastung des Webservers geknüpft ist. Client-Side-Rendering geht den umgekehrten Weg und entlastet den Server, indem ein Großteil der Seite erst im Browser gerendert wird – vorausgesetzt, der Nutzer hat JavaScript nicht blockiert. Static-Site-Generation schont sowohl Server als auch Client und sorgt dank des Prerendering-Ansatzes für eine schnelle Auslieferung des Contents, sofern es sich nicht um interaktive und sich stetig ändernde Inhalte handelt.

Alle drei aufgezeigten Strategien für das Rendering von Webprojekten haben also ihre Pros und Contras. Wägen Sie genau ab, welche Eigenschaften am besten zu Ihrem Projekt passen, um den besten Ansatz für Ihre Webanwendung zu finden.