Server Side Rendering - Ein alter Trend im neuen Gewand?

Server Side Rendering (SSR) und Static Side Generation (SSG) sind Begriffe, die in der Webentwicklung aktuell immer wieder auftauchen. Aber was bedeuten sie eigentlich und warum werden sie gerade jetzt wieder relevant, obwohl wir sie in Zeiten von Single Page Applications (SPA) nicht brauchen? Zudem fühlt es sich an, als würde eine altbekannte Technik in neuem Gewand durch das Dorf getrieben werden. PHP, ich hör dir trapsen!

Die Ära der statischen Webseiten (bis ca. 2005)

Damals™, in den Anfangstagen des Internets, waren Webseiten statische, unveränderliche Dokumente. Das bedeutete, dass jede Seite als HTML-Datei auf einem Server abgelegt, von einem Browser abgerufen, interpretiert und angezeigt wurde. Zu jener Zeit war die semantische Bedeutung der HTML-Tags auch noch dem Gros der Entwickelnden bekannt (Spoiler: semantisches HTML ist und war schon immer relevant!). Gegen Ende der 90er, mit dem Aufkommen von DHTML (Dynamic HTML: CSS und JavaScript), wurden Webseiten zunehmend dynamischer und grafisch aufwändiger. Diese Ära war geprägt von HTML-Seiten, die oft mit Tabellen als Layout-Elemente und CSS für das Styling erstellt wurden. Die Interaktivität war noch minimal und wurde hauptsächlich durch serverseitige Skripte wie PHP oder Perl realisiert.

Der Aufstieg von AJAX und dynamischen Webanwendungen (2005-2010)

Ein Wendepunkt war das Jahr 2005, als Google Maps veröffentlicht wurde und die Transition hin zu Web 2.0 manifestierte. Google Maps demonstrierte eindrucksvoll, wie AJAX (Asynchronous JavaScript and XML) genutzt werden konnte, um dynamische Inhalte zu laden, ohne die gesamte Webseite neu aufbauen zu müssen. Das war der Beginn einer neuen Ära in der Webentwicklung, in der Benutzererfahrung und Interaktivität im Vordergrund standen. In den folgenden Jahren wurde AJAX immer populärer und ermöglichte die Entwicklung von dynamischen Webanwendungen. Frameworks wie jQuery erleichterten die Arbeit mit AJAX erheblich und trugen zur Verbreitung dieser Technik bei. Erst mit dem Aufkommen von Single-Page-Frameworks verlor u.a. jQuery an Bedeutung und eine professionalisierte Entwicklung von Webanwendungen nahm Fahrt auf.

Die Ära der Single-Page-Applications (SPAs) (ab 2010)

Der Aufstieg von SPAs begann etwa ab dem Jahr 2010. Mit dem Aufkommen leistungsfähiger JavaScript-Frameworks wie AngularJS (2010), React (2013) und Vue.js (2014) wurde es möglich, komplexe Anwendungen zu entwickeln. Spätestens jetzt wurde deutlich, dass der Web 2.0 Ansatz, das Internet als Plattform zu betrachten, eingeschlagen war.
SPAs laden einmal die Grundstruktur der Anwendung und aktualisieren dann dynamisch den Inhalt (genauer: das DOM) über AJAX-Anfragen. Das führte zu einer deutlich geänderten Benutzererfahrung, da Seitenwechsel schneller, flüssiger und vor allem ohne sichtbarem Neuaufbau realisiert wurden. In den letzten 15 Jahren hat sich die SPA-Entwicklung naturgemäß erheblich weiterentwickelt, und moderne Frameworks bieten neuere und ausgefeiltere Funktionen wie serverseitiges Rendering (SSR) und statische Seitengenerierung (SSG), um die Leistung und SEO weiter bzw. wieder zu verbessern. Doch warum geht man nun einen Schritt zurück? SPAs laufen ausschließlich auf dem Client (im Browser) und entlasten somit Server, warum also dieser Turn-Around? Mit SPA war doch alles schön und gut oder etwa nicht?

Was ist SSR und SSG?

Beim Server Side Rendering (SSR) wird der Inhalt einer Webseite nicht im Browser des Benutzers, sondern bereits auf dem Server generiert. Der Browser erhält dann eine fertig (vor-)gerenderte HTML-Seite. Das war früher die gängige Methode, bevor JavaScript-basierte Single-Page-Applications (SPAs) populär wurden und wird auch heute noch von vielen CM-Systemen wie Wordpress oder Typo3 implementiert.

Sowohl SSR als auch SSG generieren Inhalte statisch vor und reduzieren somit die initiale Ladezeit, da hier klassische Caching-Machanismen auf dem Server greifen können. Der wesentliche Unterschied zwischen SSR und SSG liegt im Zeitpunkt der Generierung: Bei SSR wird die HTML-Seite bei jeder Anfrage dynamisch auf dem Server generiert. Das bedeutet, dass der Server jedes Mal, wenn ein Benutzer eine Seite anfordert, die Daten abruft und das HTML-Dokument neu zusammenstellt. SSG hingegen generiert die HTML-Seiten während des Build-Prozesses, also einmalig. Die statischen HTML-Dateien werden dann auf einem Server gespeichert und bei jeder Anfrage unverändert ausgeliefert. SSG eignet sich besonders gut für Webseiten mit Inhalten, die sich selten ändern (Blogs, Wiki, Zeitungsartikel,…). SSR hingegen ist ideal für dynamische Inhalte mit hoher Benutzerinteraktion und vom Nutzenden erstellen Inhalten bzw. Inhalten, die sich im zeitlichen Verlauf sekündlich ändern können. Nimmt man es genau, sind PHP-basierte Webseiten dem SSR zuzuordnen, da hier bei jedem Aufruf das PHP-Skript erneut ausgeführt wird und die Daten an den Client schickt.

Die Renaissance von SSR

Dass SSR ein wiederaufgelebtes Thema in der Webentwicklung ist, lässt sich auf mehrere Schlüsselfaktoren zurückführen: Unter anderem ist die Performance von SSR-basierten Anwendungen besser gegenüber den Applikationen, die mit SPA-Frameworks erstellt werden. Moderne SSR-Frameworks nutzen etablierte Caching-Strategien und Edge-Computing, um schnelle Ladezeiten zu gewährleisten. Das bedeutet, dass Benutzer Webseiteninhalte schneller sehen (First Contentful Paint (FCP)) und interagieren können. Außerdem ist SSR ideal für Suchmaschinenoptimierung (SEO), da der Inhalt direkt als HTML ausgeliefert wird. Suchmaschinen-Crawler können den Inhalt leicht lesen und indexieren, was zu einer besseren Sichtbarkeit und einem höheren Ranking in den Suchergebnissen führen kann. Schließlich trägt die schnellere Ladezeit von SSR-Anwendungen auch zu einer besseren Benutzererfahrung bei. Benutzer schätzen schnelle Webseiten, was zu geringeren Absprungraten und einer höheren Benutzerzufriedenheit führt und bei Shopsystemen nicht selten zu mehr Abschlüssen.

Doch was macht SSR aktuell so besonders, wenn bspw. PHP dies seit jeher “von Haus aus” macht? Ein wesentlicher Aspekt ist, dass kein Framework- oder Technologie-Bruch stattfinden muss: Verwendet man Next.js, Nuxt.js oder Angular in einer aktuellen Version, kann mit den vom jeweiligen Framework angebotenen Feature-Set für beide Seiten, Client- und Server, entwickelt werden. Überspitzt gesagt reicht es aus, Grundlagen der Webentwicklung, Typescript und eins der großen Frameworks zu kennen statt zusätzlich noch die weiteren rein Server-seitigen Sprachen wie PHP oder ASP.NET. Zudem ist durch den Einsatz der Ursprünglich für den SPA-Fokus entwickelten Frameworks ein hybrider Betrieb möglich: Die Webapplikation wird zunächst ohne weitere Notwendigkeit für JavaScript an den Browser ausgespielt und anschließend über “hydration” mit Hilfe von JavaScript-Funktionen um Interaktive Elemente angereichert.

Fazit

Auch wenn es den Anschein hat, ist SSR kein alter Trend im neuen Gewand, sondern ein topaktuelles Thema mit wesentlichen Weiterentwicklungen. Wer eine performante, SEO-freundliche und benutzerfreundliche Website entwickeln möchte, sollte sich mit SSR auseinandersetzen und über bekannte Muster aus PHP oder .NET-Zeiten hinaus blicken. Seit der Einführung dieser Technologien hat sich die Internetarchitektur maßgeblich weiterentwickelt und die neuen Webframeworks machen sich dies zu Nutzen und ermöglichen es, die Konzepte wie CDNs, Caching, Edge-Computing einfacher und für den Entwickelnden transparenter zu nutzen.