Wir kehren zu den Grundlagen von Composable-Architekturen zurück und beleuchten dabei einige der wichtigsten Fachbegriffe, die man beim Aufbau eines modernen Web-Erlebnisses verstehen sollte.

Beim Aufbau digitaler Erlebnisse bringt die moderne Webentwicklung jeden Tag neue Trends hervor – sei es die Anwendung neuer Technologien oder die Rückbesinnung auf Grundlagen.

In diesem Beitrag erklären wir die Unterschiede zwischen Single Page Application (SPA), Server-Side Rendering (SSR) und Static Site Generator (SSG). Sie bilden das Rückgrat moderner Web-Erfahrungen. Jeder Ansatz hat ideale Anwendungsfälle, in denen die Art des Inhalts von dem jeweiligen Frontend-Muster profitiert.

#Was ist eine Single Page Application (SPA)?

Eine Single Page Application ist ein weit gefasster Oberbegriff für Anwendungen, die beim Aufruf durch den Client gerendert werden. SPAs bestehen aus einer einzigen HTML-Seite, die keine vorab geladenen Inhalte enthält. Inhalte werden über Javascript-Dateien für die gesamte Anwendung geladen und innerhalb einer einzigen HTML-Seite verwaltet. Die Javascript-Dateien enthalten alle Daten zur Anwendungslogik, zur Benutzeroberfläche und zur Kommunikation mit dem Server.

Zu den beliebten Javascript-Frameworks und Bibliotheken für den Aufbau von SPAs gehören unter anderem die üblichen Verdächtigen wie React, AngularJS, Vue.js, Ember.JS und Svelte.

Wenn Nutzer zwischen den verschiedenen Bereichen der SPA navigieren, entstehen keine zusätzlichen Ladezeiten zwischen den einzelnen Elementen der Anwendung.

Die Vorteile

• Auch wenn der initiale Ladevorgang länger dauern kann, ist nach dem vollständigen Laden der Anwendung kein weiteres Laden mehr erforderlich
• Eine gute Wahl für dynamische Erlebnisse, bei denen Teams ein individuelles Gefühl für ihr Nutzererlebnis benötigen
• Teams haben viel Kontrolle über ihre Architekturen und können moderne Web-Frameworks nutzen
• Kann in Kombination mit anderen Technologien eingesetzt werden

Die Nachteile

• Mit wachsender Größe und Komplexität der Anwendung kann sich die anfängliche Ladezeit erheblich verschlechtern
• Gute SEO-Ergebnisse zu erzielen ist aufgrund der Ladezeiten und des Fehlens von initialem Inhalt im HTML nahezu unmöglich
• Große Dateien für komplexe Webanwendungen können schwer zu pflegen und zu organisieren werden
• Herausforderungen des SPA-Ansatzes erfordern Workarounds, die kostspielig und zeitaufwendig sein können

Wann sollte man Single Page Applications einsetzen

SPAs eignen sich zwar hervorragend für interaktive, personalisierte Erlebnisse, werden jedoch aufgrund ihrer langen Ladezeiten nicht für Konzepte mit umfangreichen Inhalten empfohlen.

#Was ist Server-Side Rendering (SSR)?

Beim Server-Side Rendering erhalten Clients eine vollständig gerenderte Seite auf Anfrage, anstatt mehrere Sekunden auf das Laden bestimmter Elemente warten zu müssen. Das Rendering erfolgt auf dem Server, bevor die Seite an den Browser übergeben wird. Wenn Inhalte clientseitig angefordert werden, werden die Daten aus einer Datenbank oder einem CMS abgerufen, während die Nutzer durch die Seite navigieren.

Das bedarfsgerechte Laden aller Inhalte macht den Prozess langsamer, stellt aber sicher, dass die Inhalte stets aktuell sind und Änderungen sofort live verfügbar sind. Einige Elemente können zwischengespeichert werden, etwa Assets und CSS-Dateien und sogar manche serverseitig gerenderten Seiten, doch in der Regel werden die Daten bei jeder Anfrage direkt aus der Datenbank abgerufen.

Die Vorteile

• SSR ermöglicht es Teams, dynamische, personalisierte Content-Erlebnisse ohne aufwendige Workarounds zu schaffen
• Änderungen an Inhalten werden sofort angezeigt, im Gegensatz zu SSGs, bei denen Teams die Website erst neu erstellen müssen
• SSR-Websites sind client-agnostisch, im Unterschied zu SPAs, bei denen der Client die Ladezeit oder Qualität der Seite bestimmen kann
• Mit SSR lässt sich leichter gutes SEO-Ranking erzielen als mit SPAs, während gleichzeitig personalisierte Erlebnisse geboten werden

Die Nachteile

• SSR erfordert in der Regel mehr API-Aufrufe an den Server
• SSR ist standardmäßig oft langsamer als SPAs und SSGs

Wann sollte man Server-Side Rendering einsetzen

Server-Side Rendering ermöglicht es Teams, dynamische Content-Erlebnisse bereitzustellen, die personalisiert werden können. Es eignet sich ideal für personalisierte Erlebnisse, bei denen Live-Änderungen an den Daten sichtbar sein sollen.

Serverseitig gerenderte Websites (bzw. serverseitig gerenderte Anwendungen, kurz SRAs) sind eine ausgezeichnete Wahl für zeitkritische Inhalte und Anwendungen, die auf einem hohen Maß an Nutzerinteraktion beruhen. Mit SSR ist Personalisierung deutlich einfacher umzusetzen und kann eine gute Option für den E-Commerce sein. Bei SSR ist es wichtig sicherzustellen, dass deine Infrastruktur die Anfragen an die Server bewältigen kann und dass die Server bei steigendem Traffic problemlos skalieren können.

#Was ist ein Static Site Generator (SSG)

Während SPAs alle ihre Daten auf einer einzigen HTML-Seite laden, die erst nach einer Client-Anfrage gerendert wird, verfolgen Static Site Generators einen ganz anderen Ansatz für Inhalte und den Seitenaufbau im Allgemeinen.

Static Site Generators generieren Inhalte zum Build-Zeitpunkt neuer Seiten oder wenn Änderungen an den Inhalten vorgenommen werden. Da SSGs statische Websites erzeugen, müssen Seiten nicht auf Basis von Nutzeranfragen geladen werden. Der Inhalt bleibt unabhängig von den Nutzer stets konsistent.

Die Vorteile

• Einfache Erstellung einer entkoppelten Architektur mit mehreren Content-Quellen
• Schnelle Seitenladezeiten, da ein Großteil des Inhalts vorgerendert wird und der Inhalt statischer Natur ist
• Besser für SEO
• Einfach skalierbare Infrastruktur, die es dem Projekt ermöglicht, organisch zu wachsen

Die Nachteile

• Personalisierung und dynamische Inhalte erfordern Workarounds oder zusätzliche Services
• Wenn sich Inhalte ändern, muss die Website neu erstellt werden, damit diese Änderungen auf der Seite sichtbar werden

Wann sollte man Static Site Generators einsetzen

Der Einsatz von SSGs als Teil des Tech-Stacks ermöglicht es Teams, Daten aus mehreren Datenquellen abzurufen, und lässt Teams von modernen Ansätzen der Webentwicklung profitieren. Ideale Anwendungsfälle für den SSG-Ansatz sind solche, bei denen Inhalte nicht in hohem Maße personalisiert werden müssen.

Static Site Generators werden typischerweise gemeinsam mit einem Headless CMS, einem statischen Hosting-Dienst und einem CDN zum Zwischenspeichern aller Daten eingesetzt. Webhooks signalisieren dem SSG, dass Änderungen an den Inhalten vorgenommen wurden, woraufhin diese Änderungen auf der Website bereitgestellt werden, die im Cache gespeichert ist. CDNs ermöglichen es Teams, vorgerenderte HTML-Dateien an Orten zu speichern, die geografisch näher an der Anfrage liegen, was die Seitenladezeiten weiter reduziert. Wir sind in anderen Beiträgen bereits ausführlich auf SSGs und ihre Vorteile eingegangen, hier jedoch einige Highlights zu den Vor- und Nachteilen von SSGs.

#Welcher Ansatz ist besser?

Wie bei vielen Dingen in der Webentwicklung gibt es keine eindeutige Antwort darauf, welcher Ansatz besser ist – es kommt darauf an.

Es hängt vom Anwendungsfall und den Inhalten ab, ebenso wie von der Zielgruppe, dem Entwicklungsteam, dem Budget usw. SPAs mit clientseitigem Rendering können effektiver für die Erstellung dynamischer Web-Erlebnisse sein. Allerdings stehen Teams dabei vor den Herausforderungen der Seitenladezeiten und haben möglicherweise Schwierigkeiten mit SEO. Dynamische Inhalte, die ein hohes Maß an Personalisierung erfordern, sind wahrscheinlich besser für einen SSR-Ansatz geeignet. SSGs ermöglichen es Teams, statische Websites zu erstellen, die schnell laden und bei SEO gut abschneiden. Sie können jedoch das Ausmaß der Personalisierung und dynamischer Inhalte einschränken, ohne aufwendige Workarounds.

Es gibt einige Tools, die dabei helfen können, moderne Frameworks mit größerer Flexibilität zu verbinden. Next.js ermöglicht es dir, statische Websites zu erstellen und Server-Side Rendering über ihren hybriden Ansatz zu nutzen. Das bedeutet, dass Teams je nach idealem Anwendungsfall für die Elemente ihres Projekts von den Vorteilen von SSR oder SSG profitieren können. Die Arbeit mit Next.js kann hilfreich sein, um sicherzustellen, dass Projekte ein gutes SEO-Ranking beibehalten.