Clientseitig vs. Serverseitiges Rendering

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

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

Zwei beliebte Rendering-Methoden sind das clientseitige Rendering (CSR) und das serverseitige Rendering (SSR).

Alle Websites haben unterschiedliche Anforderungen. Wenn Sie also den Unterschied zwischen clientseitigem und serverseitigem Rendering verstehen, können Sie Ihre Website so rendern, dass sie Ihren Geschäftszielen entspricht.

Google und JavaScript

Google verfügt über eine umfangreiche Dokumentation zum Umgang mit JavaScript. Google-Mitarbeiter bieten Einblicke und beantworten regelmäßig JavaScript-Fragen in verschiedenen Formaten – sowohl offiziellen als auch inoffiziellen.

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

Dies löste eine umfangreiche Diskussion auf LinkedIn aus, und weitere Erkenntnisse aus dem Podcast und den weiteren Diskussionen sind:

• 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 insgesamt hat dazu beigetragen, viele Mythen und Missverständnisse über die Funktionsweise von Google zu zerstreuen könnte haben Ich habe mich an JavaScript gewandt und Ressourcen zugewiesen.

Der vollständige Kommentar von Martin Splitt auf LinkedIn zu diesem Thema lautete:

„Wir verfolgen nicht, wie teuer diese Seite für uns war?“ oder so. Wir wissen, dass ein erheblicher 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, da wir erst dann einigermaßen sicher sein können, dass wir den gesamten Inhalt sehen, wenn er gerendert ist.“

Martin bestätigte auch eine Warteschlange und eine mögliche Verzögerung zwischen Crawling und Indexierung, aber nicht nur, weil etwas JavaScript ist oder nicht, und es ist kein „undurchsichtiges“ Problem, dass das Vorhandensein von JavaScript die Hauptursache dafür ist, dass URLs nicht indexiert werden.

Allgemeine JavaScript-Best Practices

Bevor wir uns mit der Debatte zwischen Client- und Serverseite befassen, ist es wichtig, dass wir auch allgemeine Best Practices befolgen, damit jeder dieser Ansätze funktioniert:

• Blockieren Sie JavaScript-Ressourcen nicht durch Robots.txt oder Serverregeln.
• Vermeiden Sie Renderblockierungen.
• Vermeiden Sie es, JavaScript in das DOM einzufügen.

Was ist clientseitiges Rendering und wie funktioniert es?

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

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

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, erfolgen die nachfolgenden Seitenladevorgänge schnell, da sie nicht auf eine andere HTML-Seite pro Route angewiesen sind.

Von der Verwaltung der Logik bis zum Abrufen von Daten von einer API erledigen vom Client gerenderte Websites alles „unabhängig“. Die Seite ist verfügbar, nachdem der Code ausgeführt wurde, da jede Seite, die der Benutzer besucht, 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.
• Unter der angegebenen URL wird eine Datenanforderung an den Server gesendet.
• Bei der ersten Anfrage des Clients für die Site übermittelt der Server die statischen Dateien (CSS und HTML) an den Browser des Clients.
• Der Client-Browser lädt zuerst den HTML-Inhalt herunter, gefolgt von JavaScript. Diese HTML-Dateien verbinden das JavaScript und starten den Ladevorgang, indem sie dem Benutzer Ladesymbole anzeigen, die der Entwickler definiert. Zu diesem Zeitpunkt ist die Website für den Benutzer noch nicht sichtbar.
• Nachdem das JavaScript heruntergeladen wurde, werden Inhalte dynamisch im Browser des Clients generiert.
• Der Webinhalt wird sichtbar, wenn der Kunde 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 Informationsanfrage vom 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 der Website 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 stellt dem Browser eine bereit zum Rendern bereite HTML-Antwort bereit.
• 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 ihrer Funktionsweise. 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 Website für eine bessere SEO crawlen und so die Indexierung Ihrer Webseiten erleichtern. Diese Lesbarkeit in Textform ist genau die Art und Weise, wie SSR-Sites im Browser angezeigt werden.

Allerdings ist clientseitiges Rendering für Websitebesitzer eine günstigere Option.

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

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

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

Der Nachteil von CSR ist die längere anfängliche Ladezeit. Dies kann Auswirkungen auf die Suchmaschinenoptimierung haben. Crawler warten möglicherweise nicht darauf, dass der Inhalt geladen und die Website verlassen wird.

Dieser zweiphasige Ansatz erhöht die Möglichkeit, dass leere Inhalte auf Ihrer Seite angezeigt werden, weil JavaScript-Inhalte fehlen, nachdem der HTML-Code einer Seite zunächst gecrawlt und indiziert wurde. Denken Sie daran, dass CSR in den meisten Fällen eine externe Bibliothek erfordert.

Wann man serverseitiges Rendering verwenden sollte

Wenn Sie Ihre Google-Sichtbarkeit verbessern und auf den Ergebnisseiten der Suchmaschinen (SERPs) einen hohen Rang einnehmen möchten, ist serverseitiges Rendering 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 man clientseitiges Rendering verwenden sollte

Clientseitiges Rendering wird normalerweise mit dynamischen Web-Apps wie sozialen Netzwerken oder Online-Messengern kombiniert. Dies liegt daran, dass sich die Informationen dieser Apps ständig ändern und mit großen und dynamischen Daten umgehen müssen, um schnelle Aktualisierungen durchzuführen, um den Benutzeranforderungen gerecht zu werden.

Der Fokus liegt hier auf einer reichhaltigen Website mit vielen Benutzern, wobei das Benutzererlebnis Vorrang vor SEO hat.

Was ist besser: serverseitiges oder clientseitiges Rendering?

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

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

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

Häufigkeit der Inhaltsaktualisierung

Websites mit hochdynamischen Informationen, wie z. B. Glücksspiel- oder FOREX-Websites, aktualisieren ihren Inhalt jede Sekunde. Das bedeutet, dass Sie in diesem Szenario wahrscheinlich CSR gegenüber SSR wählen würden – oder CSR für bestimmte Landingpages und nicht für alle Seiten verwenden, je nachdem Strategie zur Benutzerakquise.

SSR ist effektiver, wenn der Inhalt Ihrer Website keine große 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 Bereitstellung von Renderings für 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 dargestellt werden sollten, damit die Crawler sie so schnell wie möglich identifizieren können, und nicht nur im gerenderten erscheinen HTML.

Ü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 Plugins oder sofort einsatzbereite Lösungen zur Verfügung als im größeren Plugin-Ökosystem, auf das auch WordPress-Benutzer Zugriff haben.

Für diejenigen, die ein Headless-WordPress-Setup in Betracht ziehen, beispielsweise die Verwendung von Frontity, ist es wichtig zu beachten, dass Sie sowohl React.js-Entwickler als auch PHP-Entwickler einstellen müssen.

Dies liegt daran, dass Headless-WordPress für das Frontend auf React.js setzt, für das Backend jedoch weiterhin PHP benötigt.

Es ist wichtig zu bedenken, dass nicht alle WordPress-Plugins mit Headless-Setups kompatibel sind, was die Funktionalität einschränken oder zusätzliche benutzerdefinierte Entwicklung 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.

Auf einem Online-Marktplatz können beispielsweise 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 haben, können Sie den Inhalt nicht für Bots per SSR rendern. Sie müssen also eine Art Standardinhalt für den Googlebot definieren, der ohne Cookies crawlt staatenlos.

Seiten wie Benutzerkonten müssen nicht in den Suchmaschinen-Ergebnisseiten (SERPs) gerankt werden, daher könnte ein CRS-Ansatz für 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 die größte inhaltsreiche Farbe: Eine einfache Erklärung
• 13 Schritte zur Steigerung der Crawlbarkeit und Indexierbarkeit Ihrer Website
• Fortgeschrittenes technisches SEO: Ein vollständiger Leitfaden

Ausgewähltes Bild: TippaPatt/Shutterstock