Clientseitiges vs. serverseitiges Rendering

Schnellere Ladezeiten von Webseiten spielen eine große Rolle für das Benutzererlebnis und die SEO, wobei die Seitenladegeschwindigkeit ein entscheidender Faktor für den Google-Algorithmus ist.

Ein Front-End-Webentwickler muss entscheiden, wie eine Website am besten gerendert wird, damit sie ein schnelles Erlebnis und dynamische Inhalte bietet.

Zwei beliebte Rendering-Methoden sind Client-Side-Rendering (CSR) und Server-Side-Rendering (SSR).

Jede Website hat andere Anforderungen. Wenn Sie also den Unterschied zwischen clientseitigem und serverseitigem Rendering verstehen, können Sie Ihre Website so gestalten, dass sie Ihren Geschäftszielen entspricht.

Google und JavaScript

Google verfügt über eine umfassende Dokumentation zum Umgang mit JavaScript. Darüber hinaus bieten Google-Mitarbeiter Einblicke und beantworten regelmäßig JavaScript-Fragen in verschiedenen offiziellen und inoffiziellen Formaten.

Beispielsweise wurde in einem Search Off The Record-Podcast besprochen, dass Google alle Seiten für die Suche rendert, auch solche mit viel JavaScript.

Dies löste eine umfangreiche Diskussion auf LinkedIn aus. Aus dem Podcast und den anschließenden Diskussionen konnten wir folgende Erkenntnisse gewinnen:

• Google erfasst nicht, wie teuer das Rendern bestimmter Seiten ist.
• Google rendert alle Seiten, um Inhalte anzuzeigen – unabhängig davon, ob JavaScript verwendet wird oder nicht.

Das Gespräch als Ganzes hat dazu beigetragen, viele Mythen und Missverständnisse darüber zu zerstreuen, wie Google könnte habe mich JavaScript genähert und Ressourcen zugewiesen.

Martin Splitts vollständiger Kommentar hierzu auf LinkedIn lautete:

„Wir führen keine Aufzeichnungen darüber, wie teuer diese Seite für uns war oder so etwas. Wir wissen, dass ein wesentlicher Teil des Webs JavaScript verwendet, um Inhalte auf Webseiten hinzuzufügen, zu entfernen oder zu ändern. Wir müssen nur rendern, um alles zu sehen. Es spielt keine Rolle, ob eine Seite JavaScript verwendet oder nicht, denn wir können nur einigermaßen sicher sein, alle Inhalte zu sehen, wenn sie gerendert sind.“

Martin bestätigte auch eine Warteschlange und potenzielle Verzögerung zwischen Crawling und Indizierung, allerdings nicht nur, weil etwas JavaScript ist oder nicht. Auch ist es keine „undurchsichtige“ Frage, ob die Anwesenheit von JavaScript die Hauptursache dafür ist, dass URLs nicht indiziert werden.

Allgemeine Best Practices für JavaScript

Bevor wir uns mit der Debatte „Clientseitig versus Serverseitig“ befassen, ist es wichtig, dass wir auch die allgemeinen Best Practices befolgen, damit einer dieser Ansätze funktioniert:

• Blockieren Sie JavaScript-Ressourcen nicht über Robots.txt oder Serverregeln.
• Vermeiden Sie Renderblockierungen.
• Vermeiden Sie das Einfügen von JavaScript in das DOM.

Was ist Client-Side-Rendering und wie funktioniert es?

Clientseitiges Rendering ist ein relativ neuer Ansatz zum Rendern von Websites.

Es wurde populär, als JavaScript-Bibliotheken begannen, es zu integrieren, wobei Angular und React.js einige der besten Beispiele für Bibliotheken sind, die bei dieser Art des Renderings verwendet werden.

Es funktioniert, indem das JavaScript einer Website in Ihrem Browser und nicht auf dem Server gerendert wird.

Der Server antwortet mit einem einfachen HTML-Dokument, das die JS-Dateien enthält, anstatt den gesamten Inhalt aus dem HTML-Dokument abzurufen.

Während die anfängliche Upload-Zeit etwas langsam ist, werden nachfolgende Seiten schnell geladen, da sie nicht von einer anderen HTML-Seite pro Route abhängig sind.

Von der Verwaltung der Logik bis zum Abrufen von Daten aus einer API erledigen vom Client gerenderte Websites alles „unabhängig“. Die Seite ist verfügbar, nachdem der Code ausgeführt wurde, da jede vom Benutzer besuchte Seite und die entsprechende URL dynamisch erstellt werden.

Der CSR-Prozess läuft wie folgt ab:

• Der Benutzer gibt die URL, die er besuchen möchte, in die Adressleiste ein.
• Es wird eine Datenanforderung an den Server unter der angegebenen URL gesendet.
• Bei der ersten Anforderung der Site durch den Client liefert der Server die statischen Dateien (CSS und HTML) an den Browser des Clients.
• Der Client-Browser lädt zuerst den HTML-Inhalt und dann JavaScript herunter. Diese HTML-Dateien binden das JavaScript ein und starten den Ladevorgang, indem sie dem Benutzer vom Entwickler definierte Ladesymbole anzeigen. Zu diesem Zeitpunkt ist die Website für den Benutzer noch nicht sichtbar.
• Nachdem das JavaScript heruntergeladen wurde, wird der Inhalt dynamisch im Browser des Clients generiert.
• Der Webinhalt wird sichtbar, während der Client auf der Website navigiert und mit ihr interagiert.

Was ist serverseitiges Rendering und wie funktioniert es?

Serverseitiges Rendering ist die gebräuchlichere Technik zum Anzeigen von Informationen auf einem Bildschirm.

Der Webbrowser sendet eine Informationsanforderung an den Server, ruft benutzerspezifische Daten zum Auffüllen ab und sendet eine vollständig gerenderte HTML-Seite an den Client.

Jedes Mal, wenn der Benutzer eine neue Seite auf der Site besucht, wiederholt der Server den gesamten Vorgang.

So läuft der SSR-Prozess Schritt für Schritt ab:

• Der Benutzer gibt die URL, die er besuchen möchte, in die Adressleiste ein.
• Der Server liefert dem Browser eine renderfertige HTML-Antwort.
• Der Browser rendert die Seite (jetzt sichtbar) und lädt JavaScript herunter.
• Der Browser führt React aus und macht so die Seite interaktiv.

Was sind die Unterschiede zwischen clientseitigem und serverseitigem Rendering?

Der Hauptunterschied zwischen diesen beiden Rendering-Ansätzen liegt in den Algorithmen, mit denen sie arbeiten. CSR zeigt vor dem Laden eine leere Seite an, während SSR beim ersten Laden eine vollständig gerenderte HTML-Seite anzeigt.

Dies verschafft dem serverseitigen Rendering einen Geschwindigkeitsvorteil gegenüber dem clientseitigen Rendering, da der Browser keine großen JavaScript-Dateien verarbeiten muss. Inhalte sind oft innerhalb weniger Millisekunden sichtbar.

Suchmaschinen können die Site für eine bessere SEO crawlen, was die Indexierung Ihrer Webseiten erleichtert. Diese Lesbarkeit in Textform ist genau die Art und Weise, wie SSR-Sites im Browser angezeigt werden.

Für Websitebesitzer ist das clientseitige Rendering jedoch eine kostengünstigere Option.

Es entlastet Ihre Server, indem es die Verantwortung für das Rendering an den Client übergibt (den Bot oder Benutzer, der versucht, Ihre Seite anzuzeigen). Es bietet außerdem umfangreiche Site-Interaktionen, indem es nach dem ersten Laden eine schnelle Website-Interaktion ermöglicht.

Bei CSR werden weniger HTTP-Anfragen an den Server gestellt, anders als bei SSR, wo jede Seite von Grund auf neu gerendert wird, was zu einem langsameren Übergang zwischen den Seiten führt.

SSR kann auch bei hoher Serverlast zusammenbrechen, wenn der Server viele gleichzeitige Anfragen von verschiedenen Benutzern erhält.

Der Nachteil von CSR ist die längere anfängliche Ladezeit. Dies kann sich auf die SEO auswirken; Crawler warten möglicherweise nicht, bis der Inhalt geladen ist, und verlassen die Site.

Bei diesem zweistufigen Ansatz besteht die Möglichkeit, dass auf Ihrer Seite leerer Inhalt angezeigt wird, da JavaScript-Inhalte nach dem ersten Crawlen und Indizieren des HTML einer Seite fehlen. Denken Sie daran, dass CSR in den meisten Fällen eine externe Bibliothek erfordert.

Wann sollte serverseitiges Rendering verwendet werden?

Wenn Sie Ihre Sichtbarkeit bei Google verbessern und in den Suchergebnisseiten (SERPs) einen hohen Rang erreichen möchten, ist die serverseitige Darstellung die erste Wahl.

E-Learning-Websites, Online-Marktplätze und Anwendungen mit einer einfachen Benutzeroberfläche mit weniger Seiten, Funktionen und dynamischen Daten profitieren alle von dieser Art der Darstellung.

Wann sollte clientseitiges Rendering verwendet werden?

Clientseitiges Rendering wird normalerweise mit dynamischen Webanwendungen wie sozialen Netzwerken oder Online-Messengern kombiniert. Dies liegt daran, dass sich die Informationen dieser Anwendungen ständig ändern und sie große und dynamische Daten verarbeiten müssen, um schnelle Aktualisierungen durchzuführen und so die Benutzernachfrage zu erfüllen.

Der Schwerpunkt liegt hier auf einer umfangreichen Site mit vielen Benutzern, wobei das Benutzererlebnis Vorrang vor SEO hat.

Was ist besser: serverseitiges oder clientseitiges Rendering?

Um zu entscheiden, welcher Ansatz der beste ist, müssen Sie nicht nur Ihre SEO-Anforderungen berücksichtigen, sondern auch, wie die Website für die Benutzer funktioniert und einen Mehrwert bietet.

Denken Sie über Ihr Projekt nach und darüber, wie sich die von Ihnen gewählte Darstellung auf Ihre Position in den SERPs und die Benutzererfahrung Ihrer Website auswirkt.

Im Allgemeinen ist CSR besser für dynamische Websites geeignet, während SSR am besten für statische Websites geeignet ist.

Häufigkeit der Inhaltsaktualisierung

Websites mit hochdynamischen Informationen, wie etwa Glücksspiel- oder FOREX-Websites, aktualisieren ihre Inhalte jede Sekunde. Das bedeutet, dass Sie in diesem Szenario wahrscheinlich CSR statt SSR wählen würden – oder sich, abhängig von Ihrer Strategie zur Benutzergewinnung, dafür entscheiden würden, CSR nur für bestimmte Zielseiten und nicht für alle Seiten zu verwenden.

SSR ist effektiver, wenn der Inhalt Ihrer Site nicht viel Benutzerinteraktion erfordert. Es wirkt sich positiv auf Zugänglichkeit, Seitenladezeiten, SEO und Social-Media-Unterstützung aus.

Andererseits eignet sich CSR hervorragend für die kostengünstige Darstellung von Webanwendungen und ist einfacher zu erstellen und zu warten; es ist besser für First Input Delay (FID).

Eine weitere CSR-Überlegung besteht darin, dass Meta-Tags (Beschreibung, Titel), kanonische URLs und Hreflang-Tags serverseitig gerendert oder in der ersten HTML-Antwort angezeigt werden sollten, damit die Crawler sie so schnell wie möglich identifizieren können und nicht nur im gerenderten HTML erscheinen.

Überlegungen zur Plattform

Die Wartung der CSR-Technologie ist tendenziell teurer, da der Stundensatz für Entwickler mit Kenntnissen in React.js oder Node.js im Allgemeinen höher ist als der für PHP- oder WordPress-Entwickler.

Darüber hinaus stehen für CSR-Frameworks weniger vorgefertigte Plug-Ins oder sofort einsatzbereite Lösungen zur Verfügung als für WordPress-Benutzer. Das größere Plug-In-Ökosystem steht ebenfalls zur Verfügung.

Wenn Sie eine Headless-WordPress-Konfiguration in Erwägung ziehen, beispielsweise mit Frontity, sollten Sie beachten, dass Sie sowohl React.js- als auch PHP-Entwickler einstellen müssen.

Dies liegt daran, dass Headless-WordPress für das Front-End auf React.js setzt, für das Back-End aber weiterhin PHP benötigt.

Es ist wichtig zu beachten, dass nicht alle WordPress-Plugins mit Headless-Setups kompatibel sind, was die Funktionalität einschränken oder zusätzliche benutzerdefinierte Entwicklungen erfordern könnte.

Funktionalität und Zweck der Website

Manchmal müssen Sie sich nicht zwischen beiden entscheiden, da Hybridlösungen verfügbar sind. Sowohl SSR als auch CSR können auf einer einzigen Website oder Webseite implementiert werden.

Beispielsweise können in einem Online-Marktplatz Seiten mit Produktbeschreibungen auf dem Server gerendert werden, da sie statisch sind und von Suchmaschinen leicht indiziert werden müssen.

Bleiben wir beim E-Commerce: Wenn Sie auf mehreren Seiten ein hohes Maß an Personalisierung für Benutzer bieten, können Sie den Inhalt für Bots nicht per SSR rendern. Daher müssen Sie eine Art Standardinhalt für Googlebot definieren, der ohne Cookies und Status crawlt.

Seiten wie Benutzerkonten müssen nicht in den Suchmaschinenergebnisseiten (SERPs) eingestuft werden, daher könnte ein CRS-Ansatz für die UX besser sein.

Sowohl CSR als auch SSR sind beliebte Ansätze zum Rendern von Websites. Sie und Ihr Team müssen diese Entscheidung in der Anfangsphase der Produktentwicklung treffen.

Weitere Ressourcen:

• Was ist Largest Contentful Paint: Eine einfache Erklärung
• 13 Schritte zur Verbesserung der Crawlbarkeit und Indexierbarkeit Ihrer Site
• Fortgeschrittenes technisches SEO: Ein vollständiger Leitfaden

Vorgestelltes Bild: TippaPatt/Shutterstock