SSR vs. CSR – was ist die richtige Wahl für Ihre Progressive Webanwendung (PWA)?

Die Faktoren und Überlegungen, die Ihre Entscheidung beeinflussen sollten, ob Sie eine Webanwendung mit server- oder client-seitigem Rendering erstellen sollten.

Mobilen App-EntwicklungUPDATED ON Oktober 13, 2021

Translated by:

In diesem Beitrag werfen wir einen genaueren Blick auf die Auswirkungen der Wahl zwischen serverseitigem Rendering (SSR) und clientseitigem Rendering (CSR) im Zusammenhang mit der Entwicklung progressiver Webanwendungen (PWA). Eine Gegenüberstellung von SSR und CSR. Natürlich ist es nicht so eindeutig, ob CSR oder SSR von Natur aus besser ist als das jeweils andere. Die optimale Wahl zwischen den beiden im Zusammenhang mit einer bestimmten progressiven Webanwendung hängt von einer Kombination aus den Besonderheiten des technischen Anwendungsfalls und den strategischen Prioritäten ab.

CSR wird zum Beispiel am häufigsten für eine PWA gewählt, die dynamische Inhalte darstellt. Facebook ist das perfekte Beispiel für eine CSR-Website bzw. -App, bei der sich die Seite automatisch mit neuen Daten aktualisiert, ohne dass der Nutzer eine Anfrage stellen muss. Tatsächlich war es die Veröffentlichung der React library durch Facebook, die einen CSR-Ansatz bei Anwendungen populär gemacht hat.

Bei einer webbasierten Anwendung, die hauptsächlich statische Inhalte bereitstellt, wie diese Website, würde man hingegen erwarten, dass sie sich für einen SSR-Ansatz entscheidet. Eines der Hauptargumente dafür (obwohl CSR erhebliche Fortschritte in dieser Richtung macht, auf die wir später noch näher eingehen werden) ist, dass SSR im Zusammenhang mit der Suchmaschinenoptimierung (SEO) traditionell die bessere Wahl ist, weil SSR-Seiten für Suchmaschinen-Bots und Crawler besser zugänglich sind.

SSR vs CSR comparison table of strengths and weaknesses in German

Werfen wir doch einen Blick auf die genaueren Details der Entscheidung SSR vs. CSR im Kontext von PWAs. Wir beginnen mit einem kurzen Blick auf Web-Apps und dann auf progressive Web-Apps im Allgemeinen – was sie sind und welche Vorteile sie im Vergleich zur Alternative einer nativen App haben. Anschließend gehen wir auf die technischen Details des serverseitigen und des clientseitigen Renderings sowie auf ihre Stärken und Schwächen in verschiedenen Kontexten ein.

Können wir Ihnen bei Ihrem nächsten Softwareentwicklungsprojekt helfen?

Flexible Modelle für Ihre Bedürfnisse!

Web-Apps vs. Native-Apps

Wenn Sie oder Ihr Unternehmen die Entscheidung getroffen haben, eine erstklassige App zu entwickeln, müssen Sie nun festlegen, auf welchem Tech-Stack diese App aufgebaut werden soll. Die erste große Entscheidung über dem Tech-Stack ist dann oft, ob die App eine Web- oder eine native App sein soll. Jede Entscheidung hat ihre Vor- und Nachteile.

Vorteile – Web-Apps

  1. Einfache Weitergabe– Web-Apps lassen sich leicht über Links weitergeben, was bedeutet, dass sie über soziale Netzwerke oder jede andere Website oder sogar über Suchergebnisse bekannt gemacht werden können.
  2. Keine Installation erforderlich– um eine Web-App zu nutzen, muss der Nutzer nur auf den Link klicken und schon ist er in der App. Diese wird über einen Browser geöffnet und ausgeführt. Es muss nie eine Software auf ein Gerät heruntergeladen werden.
  3. Multiplattform– da eine Web-App auf einem Browser und nicht auf der Hardware läuft, hat sie eine sehr große Reichweite und läuft gleichermaßen auf so gut wie jedem Gerät mit einem Bildschirm, einem Internetbrowser und einer guten Internetverbindung. Das Einzige, worüber sich die Softwareentwickler Gedanken machen müssen, ist die Reaktionsfähigkeit der App auf unterschiedliche Bildschirmgrößen, wie z. B. bei Desktops und Handys.

Vorteile – Native-Apps

  1. Einfacher Gerätezugriff– kein Öffnen eines Browsers oder Aufrufen einer URL erforderlich. Klicken Sie einfach auf das App-Symbol auf dem Gerät und die App wird geöffnet und kann sofort verwendet werden.
  2. Schnellere Ladezeiten– da die Software bereits auf dem Gerät installiert ist und die Inhalte nur noch aktualisiert werden müssen, sind native Apps weniger auf die Übertragung von Daten über eine Internetverbindung angewiesen und laden daher grundsätzlich schneller.
  3. Besserer Hardwarezugriff– native Apps können die Hardwarefähigkeiten des Geräts, auf dem sie installiert sind, wie Verarbeitungsleistung, Grafikkarten, Kameras und Mikrofone, besser und reibungsloser nutzen.

Progressive Web-Anwendungen kombinieren die Stärken von Web- und Native-Apps.

Die gute Nachricht ist, dass progressive Web-Anwendungen (PWAs) die Stärken von Web-Apps und Native-Apps durch einen immer kleiner werdenden Kompromiss vereinen. Dies kann oft das Gleichgewicht der Überlegungen zugunsten einer Web-App anstelle einer Native-App verändern.

Was ist der Unterschied zwischen einer normalen Web-App und einer progressiven Web-App?

Wie reguläre Web-Apps werden auch PWAs im Web aufgebaut und betrieben. Allerdings bietet eine progressive Web-App auch einige Funktionen einer Native-App wie Push-Benachrichtigungen und die Tatsache, dass sie auf einem Gerät installiert werden kann. Gibt es also einen Unterschied zwischen einer progressiven Web-App und einer installierbaren Webseite? PWAs haben jedoch noch mehr zu bieten. Um sich als „progressiv“ zu bezeichnen, muss eine Webanwendung eine Reihe von Kriterien erfüllen:

  • Zuverlässigkeit– eine progressive Web-App sollte sofort laden und immer verfügbar sein.
  • Geschwindigkeit– eine PWA sollte schnell sein bzw. Sofort auf Benutzerinteraktionen reagieren können.
  • Natürliches Erlebnis– eine Progressive Web-App sollte ansprechend sein und sich auf dem Endgerät wie eine Native-App anfühlen.

Progressive Webanwendungen verfügen außerdem über zwei grundlegende technische Komponenten:

  1. The Manifest– eine JSON-Datei, die den gesamten Code enthält, der das visuelle Erscheinungsbild des Front-Ends der App bestimmt. Hier ein Beispiel auf Github.
  2. The service worker– eine JavaScript-Datei, die mit dem Browser zusammenarbeitet, um eine Schicht zwischen Ihrer App und dem Netzwerk zu bilden. Der „service worker“ ermöglicht Operationen und Funktionen wie schnelles Laden, Caching, Benachrichtigungen und Hintergrundsynchronisation.

Da PWAs auf eine einzige Codebasis zurückgreifen, die eine Reihe von Bildschirmgrößen berücksichtigt, funktionieren sie sowohl auf mobilen als auch auf Desktop-Geräten. Kurz gesagt, der Vorteil von progressiven Web-Apps ist die Reichweite des gesamten Webs, während sie den ansprechenden Funktionen von Native-Apps sehr nahekommen.

All das ist der Grund, warum wir bei K&C PWAs so sehr lieben. Und wenn Sie sich aus strategischen Gründen entschieden haben, mit Ihrer nächsten App den Weg der Progressive Web-App zu gehen, sollten Sie sich als nächstes die Frage stellen, ob das Rendering serverseitig oder clientseitig erfolgen soll.

SSR vs. CSR – was ist der Unterschied und warum ist er so wichtig?

In der Vergangenheit wurde beim Öffnen einer webbasierten Anwendung der HTML-Code, aus dem die Benutzeroberfläche und der Inhalt bestehen, durch serverseitiges Rendering (SSR) auf den Bildschirm des Geräts gebracht. Der Browser sendet eine Anfrage an den Server der Anwendung, der eine Datei mit den Daten sendet, die für die lokale Wiedergabe der Seite auf dem Gerät des Benutzers erforderlich sind.

Wenn der Nutzer auf eine andere Seite klickt oder die aktuelle Seite aktualisiert, wird der gesamte Prozess mit einer einzigen monolithischen Datei wiederholt. Diese enthält den Code der zu ladenden Seite, der vom Server der Anwendung gesendet wird.

Das Aufkommen von JavaScript-Frameworks, insbesondere React von Facebook, bot Softwareentwicklern eine neue Möglichkeit. Sie nutzten die zunehmende Leistungsfähigkeit von Internetbrowsern und die sich verbessernden mobilen Internetgeschwindigkeiten in den Industrieländern, um Seiten auf dem Bildschirm eines Nutzers darzustellen. Dies wird als CSR oder clientseitiges Rendering bezeichnet.

Bei CSR stellt der Browser eine erste Anfrage an ein Content Delivery Network (CDN) und nicht an einen Server, der einen Basis-„Wrapper“ sendet, der alle statischen HTML-, CSS- und unterstützenden Dateielemente einer Webseite oder Anwendung enthält. Diese Elemente werden dann vom Browser zwischengespeichert, der anschließend über AJAX API-Anfragen stellt, um dynamische Inhalte abzurufen. Die JavaScript-Inhalte werden im Browser mithilfe der DOM-Verarbeitung gerendert.

CSR client-side rendering infographic

Wenn eine Seite aktualisiert wird oder der Benutzer auf eine andere Seite klickt, muss der Browser nur die dynamischen JavaScript-Elemente abrufen und rendern, nicht die gesamte Seite. Zum Beispiel ist der Feed auf einer Facebook-Seite dynamisches JavaScript, während die Kopf- und Fußzeile und viele Elemente in den Seitenleisten usw. konstant bleiben.

Bei CSR dauert das anfängliche Laden der Seite länger als bei SSR, da mehr JavaScript heruntergeladen und ausgewertet werden muss. Es muss eine zweite HTTP-Anfrage gestellt werden, um den Inhalt zu laden, und dann wird mehr JavaScript benötigt, um die Vorlage zu generieren. Selbst wenn das ursprüngliche JavaScript zwischengespeichert wird, muss es noch ausgewertet werden, und die zweite Anfrage kann erst erfolgen, wenn das Dokument geladen ist. Sobald jedoch der erste Ladevorgang abgeschlossen ist und alles, was zwischengespeichert und vom Browser analysiert werden kann, geladen wurde, sind die nachfolgenden Seitenladevorgänge schneller und reibungsloser als bei SSR, wo alle Informationen jedes Mal vom Server abgerufen werden müssen.

SSR server-side rendering infographic

Bei SSR sendet der Server den gesamten HTML-Code der Seite zum Rendern, ohne dass er vorher analysiert werden muss.

Server-seitiges Rendering (SSR) oder Client-seitiges Rendering (CSR) für Ihre Progressive Web-Anwendung (PWA)?

Die Entscheidung zwischen den beiden architektonischen Ansätzen für den Aufbau einer progressiven Web-Anwendung sollte sowohl auf der Grundlage der technischen Eigenschaften, die Sie von der Anwendung erwarten, als auch auf der Grundlage eines Verständnisses des Benutzerprofils getroffen werden. Wenn Sie z. B. wissen, dass Ihre Benutzer-Persona höchstwahrscheinlich einen aktuellen Webbrowser hat, würde das für CSR sprechen. Wenn Sie daran zweifeln und eine schlechte CSR-Benutzererfahrung den Verlust einer beträchtlichen Anzahl potenzieller Benutzer bedeuten könnte, ist SSR möglicherweise die bessere Wahl.

SSR eignet sich in der Regel am besten für Webanwendungen, die stark textbasiert sind, wie z. B. schriftliche Medienanwendungen (z. B. die Webanwendung einer Zeitung). Der zusätzliche Bedarf an Servern, den SSR mit sich bringt, bedeutet jedoch, dass bei einer großen Anzahl von Nutzern deutlich mehr Cloud-Budget verbraucht werden kann. Wenn die Skalierbarkeit von Servern ein Problem darstellt, weil Sie beispielsweise keine skalierbaren cloudbasierten Servereinrichtungen verwenden, könnte dies auch ein Problem für SSR sein.

Der Teil einer Anwendung, der in der Regel den größten Teil der Ressourcen beansprucht, ist der Datenbankzugriff. Unabhängig davon, ob eine Anwendung SSR, CSR oder einen hybriden Ansatz verwendet (was immer häufiger der Fall ist), wird eine effiziente Datenbankstruktur einen großen Einfluss auf die Leistung der Anwendung haben. CSR kann jedoch dazu beitragen, datenbankbezogene Engpässe bei stark interaktiven Anwendungen zu vermeiden.

Ein Hybrid-Ansatz – Verwendung von SSR und CSR für Ihre Progressive Web-Anwendung.

Vor allem bei größeren, anspruchsvolleren Webanwendungen wird immer häufiger ein Hybrid-Ansatz verwendet, bei dem die Vorteile von SSR und CSR kombiniert werden, soweit dies sinnvoll ist. Dies erfordert eine komplexere Architektur, kann aber für Anwendungen mit einer großen Nutzerbasis sinnvoll sein, die durch die Verringerung der Serverlast in einigen Bereichen durch CSR anstelle von CSR große Summen einsparen können. Zudem haben sie textlastige Abschnitte wie beispielsweise in einem Blog, wo die Stärken von SSR zum Tragen kommen.

Für einige Anwendungen kann es relativ klar sein, dass entweder SSR oder CSR die bessere bzw. notwendige Wahl ist. Bei anderen ist die Entscheidung weniger eindeutig und beide Optionen haben Vor- und Nachteile. Diese gilt es strategisch abzuwägen, um eine Entscheidung zu treffen oder einen Hybrid-Ansatz zu wählen.

Wenn Sie die Vor- und Nachteile von SSR, CSR oder einer Mischung aus beidem im Rahmen eines PWA-Entwicklungsprojekts diskutieren möchten, kontaktieren Sie uns doch einfach. Wir helfen Ihnen gerne!

K&C - Wir schaffen innovative Tech-Lösungen seit über 20 Jahren.

Kontaktieren Sie uns, um Ihre individuellen Bedürfnisse oder Ihr nächstes Projekt zu diskutieren.