Basics kann man immer wieder mal auffrischen oder sich neu anlesen. Heute geht es um CSR und SSR und was diese beiden Rendering-Architekturen im Hinblick auf Website Performance bedeuten. Auf seinem Blog hat TK das für uns einmal im Detail aufgedröselt.
Hier ist einmal eine möglichst knappe und kurze Zusammenfassung für Dich.
Anhand der Namen kann man ja den wesentlichen Unterschied der beiden Ansätze gut herleiten:
-
Entweder findet das Rendering auf dem Client statt ➔ Client Side Rendering oder kurz CSR
-
Oder das Rendering passiert auf dem Server ➔ Server Side Rendering oder kurz SSR
So weit, so klar.
Client Side Rendering: Mach doch selber!
Beim CSR ist der Ablauf ungefähr so:
-
Der Client (also der Browser) schickt einen Request
-
Nach dem Verbindungsaufbau bekommt er ein schlankes HTML mit einem JavaScript Bundle
-
Das JS führt der Client nun selbst aus und lädt Dateien herunter, parst sie und führt sie aus
-
Dann wird die Website langsam interaktiv
-
Daten werden gefetched
-
Der Inhalt wird direkt auf der Seite gerendert
Einige dieser Schritte bergen Stolperfallen für die Performance. Vor allem das Herunterladen, Parsen und Ausführen der JS-Dateien hat es in sich:
"The most problematic part is the need for browsers to download, parse, and execute the generated bundle and only then be able to fetch the data and finally render the content on the page. (...)
The time it takes to handle this whole process is relied on the user's device.
If it's more powerful and the internet connection is good, browsers can handle it well with a certain limit.
It can be a huge performance bottleneck if the device is less powerful or the connection is not good (3g or worse)."
Denn die Performance hängt hier gänzlich an einem seidenen Faden, der vom Gerät des Nutzers und der verfügbaren Verbindung anhängt. Ist beides halbwegs solide, ist es das Rendering auch. Wenn nicht... dann nicht.
Unter diesen Bedingungen auf irgendwelche CWV-Metriken zu optimieren ist schon irgendwie wild und auch nicht so wirklich realistisch.
"CSR cannot get good performance as measured by Core Web Vitals (CWV). SSR / SSG can, but it's not a guarantee. If good performance is important in your use-case then you will need to move beyond CSR."
Server Side Rendering: Der Server serviert
Im Gegensatz zum CSR findet das Rendering und alles, was dafür im Vorhinein erforderlich ist, auf dem Server statt. D. h.
-
Alle benötigten Daten werden vom Server geholt
-
Alles wird auf dem Server in HTML gerendert und dann in der Antwort geschickt
-
Der Client lädt dann den gesamten JavaScript Code und verbindet es mit dem vom Server generierten HTML
Dabei folgen die einzelnen Schritte step by step aufeinander, es kann nichts parallelisiert werden.
"This means it begins with data fetching, then generate the HTML, renders the HTML on the client, loads the JavaScript bundle, and then hydrates the app. In this order, no parallelism."
Dadurch ergeben sich interessante Vorteile:
Je stärker und stabiler der Server aufgestellt ist, desto besser handlet er seine Aufgaben und es besteht keine Abhängigkeit vom Gerät des Nutzers und dessen Fähigkeiten.
Da die Seite schon vom Server generiert worden ist, ist für Nutzer direkt Inhalt sichtbar, was in Sachen Performance ebenfalls eine gute Sache ist.
Es gibt allerdings auch bei SSR ein paar Nachteile und Bottlenecks. Denen kann man zum Teil mit dem Ansatz des Streaming SSR beikommen. Da wird das HTML nicht als Ganzes, sondern in kleineren Teilen geschickt, so dass eine Parallelisierung möglich wird:
"Streaming is all about parallelizing operations.
The idea is to send HTML in chunks and progressively render it as it's received.
So, we can parallelize work on the server and send small HTML chunks over time to the client."
Wie das genau funktioniert, führt TK in seinem Post noch im Detail aus. Spannender Ansatz - ich hab den versprochenen Rahmen eines kurzen Grundlagen-Artikels aber schon lange gesprengt und überlass es daher Dir, Dich bei Interesse weiter einzulesen!
Behalte aber beim Lesen die SEO-Brille auf: Googlebot ist auch ein Client und wie Du Deine Seite rendern lässt, beeinflusst auch das Crawling. Auch das Thema Progressive Enhancement (also die grundlegende User Experience möglichst immer zu gewährleisten und mit steigenden technischen Kapazitäten Zusatz-Features zu ermöglichen) hat TK leider außen vor gelassen.