Reagieren Sie auf SEO-Strategien und Best Practices

React wurde entwickelt, um interaktive UIs zu erstellen, die deklarativ , modular und plattformübergreifend sind . Heute ist es eines der beliebtesten – wenn nicht sogar das beliebteste – JavaScript-Framework zum Schreiben leistungsfähiger Front-End-Anwendungen. React wurde ursprünglich zum Schreiben von Single Page Applications (SPAs) entwickelt und wird heute zum Erstellen vollwertiger Websites und mobiler Anwendungen verwendet.

Wenn Sie über umfangreiche Erfahrung in der konventionellen Webentwicklung verfügen und zu React wechseln, werden Sie feststellen, dass immer mehr HTML- und CSS-Code in JavaScript verschoben werden. Dies liegt daran, dass React nicht empfiehlt, UI-Elemente direkt zu erstellen oder zu aktualisieren, sondern stattdessen den „Zustand“ der UI zu beschreiben. React aktualisiert dann das DOM so, dass es auf die effizienteste Weise mit dem Status übereinstimmt.

Daher müssen alle Änderungen an der Benutzeroberfläche oder dem DOM über die Engine von React vorgenommen werden. Obwohl dies für Entwickler praktisch ist, kann dies längere Ladezeiten für Benutzer und mehr Arbeit für Suchmaschinen bedeuten, um die Inhalte zu finden und zu indizieren.

In diesem Artikel werden wir uns mit den Herausforderungen befassen, die beim Erstellen SEO-leistungsfähiger React-Apps und -Websites auftreten, und wir werden mehrere Strategien skizzieren, mit denen sie überwunden werden können.

Wie Google Webseiten durchsucht und indiziert

Google erhält über 90 % aller Online-Suchanfragen. Sehen wir uns den Crawling- und Indexierungsprozess genauer an.

Dieser Schnappschuss aus der Google-Dokumentation kann uns helfen. Bitte beachten Sie, dass dies ein vereinfachtes Blockdiagramm ist. Der eigentliche Googlebot ist weit ausgefeilter.

Zu beachtende Punkte:

1. Der Googlebot verwaltet eine Crawling-Warteschlange mit allen URLs, die er in Zukunft crawlen und indexieren muss.
2. Wenn der Crawler inaktiv ist, nimmt er die nächste URL in der Warteschlange auf, stellt eine Anfrage und ruft den HTML-Code ab.
3. Nach dem Parsen des HTML bestimmt der Googlebot, ob er JavaScript abrufen und ausführen muss, um den Inhalt wiederzugeben. Wenn ja, wird die URL zu einer Renderwarteschlange hinzugefügt.
4. Zu einem späteren Zeitpunkt ruft der Renderer JavaScript ab und führt es aus, um die Seite zu rendern. Es sendet das gerenderte HTML zurück an die Verarbeitungseinheit.
5. Die Verarbeitungseinheit extrahiert alle URLs <a> tags , die auf der Webseite erwähnt werden, und fügt sie wieder der Crawl-Warteschlange hinzu.
6. Der Inhalt wird dem Index von Google hinzugefügt.

Beachten Sie, dass es eine klare Unterscheidung zwischen der Processing -Stufe gibt, die HTML analysiert, und der Renderer -Stufe, die JavaScript ausführt.

Diese Unterscheidung besteht, weil die Ausführung von JavaScript teuer ist, da Googlebots über 130 Billionen Webseiten betrachten müssen. Wenn der Googlebot also eine Webseite crawlt, parst er sofort den HTML-Code und stellt dann das JavaScript in die Warteschlange , um es später auszuführen. In der Dokumentation von Google wird erwähnt, dass eine Seite einige Sekunden in der Rendering-Warteschlange verbleibt, obwohl es länger dauern kann.

Erwähnenswert ist auch das Konzept des Crawl-Budgets. Das Crawling von Google ist durch Bandbreite, Zeit und Verfügbarkeit von Googlebot-Instanzen begrenzt. Es weist jeder Website ein bestimmtes Budget oder Ressourcen zu, um sie zu indizieren. Wenn Sie eine große inhaltsreiche Website mit Tausenden von Seiten erstellen (z. B. eine E-Commerce-Website) und diese Seiten viel JavaScript zum Rendern des Inhalts verwenden, kann Google möglicherweise weniger Inhalt von Ihrer Website lesen.

Hinweis: Hier können Sie die Richtlinien von Google zur Verwaltung Ihres Crawl-Budgets lesen.

Warum die Optimierung von React für SEO eine Herausforderung darstellt

Unser kurzer Überblick über Googlebot, Crawling und Indizierung kratzt nur an der Oberfläche. Softwareentwickler sollten jedoch potenzielle Probleme identifizieren, mit denen Suchmaschinen konfrontiert sind, die versuchen, React-Seiten zu crawlen und zu indizieren. Jetzt können wir uns genauer ansehen, was React SEO zu einer Herausforderung macht und was Entwickler tun können, um einige dieser Herausforderungen anzugehen und zu überwinden.

Leerer First-Pass-Inhalt

Wir wissen, dass React-Anwendungen stark auf JavaScript angewiesen sind und häufig auf Probleme mit Suchmaschinen stoßen. Dies liegt daran, dass React standardmäßig ein App-Shell-Modell verwendet. Der anfängliche HTML-Code enthält keinen sinnvollen Inhalt, und ein Benutzer oder ein Bot muss JavaScript ausführen, um den tatsächlichen Inhalt der Seite anzuzeigen.

Dieser Ansatz bedeutet, dass der Googlebot beim ersten Durchlauf eine leere Seite erkennt. Der Inhalt wird von Google nur gesehen, wenn die Seite gerendert wird. Dies verzögert die Indexierung von Inhalten, wenn es sich um Tausende von Seiten handelt.

Ladezeit und Benutzererfahrung

Das Abrufen, Analysieren und Ausführen von JavaScript nimmt Zeit in Anspruch. Darüber hinaus muss JavaScript möglicherweise Netzwerkaufrufe durchführen, um den Inhalt abzurufen, und der Benutzer muss möglicherweise eine Weile warten, bevor er die angeforderten Informationen anzeigen kann.

Google hat eine Reihe von Web-Vitals in Bezug auf die Benutzererfahrung zusammengestellt, die in seinen Ranking-Kriterien verwendet werden. Eine längere Ladezeit kann sich auf den User Experience Score auswirken und Google dazu veranlassen, eine Website niedriger einzustufen.

Wir überprüfen die Website-Performance im Detail im folgenden Abschnitt.

Seiten-Metadaten

Meta- <meta> -Tags sind hilfreich, da sie es Google und anderen Social-Media-Websites ermöglichen, geeignete Titel, Miniaturansichten und Beschreibungen für Seiten anzuzeigen. Diese Websites verlassen sich jedoch auf das <head> -Tag der abgerufenen Webseite, um diese Informationen zu erhalten. Diese Websites führen kein JavaScript für die Zielseite aus.

React rendert den gesamten Inhalt, einschließlich Meta-Tags, auf dem Client. Da die App-Shell für die gesamte Website/Anwendung gleich ist, kann es schwierig sein, die Metadaten für einzelne Seiten anzupassen.

Seitenverzeichnis

Eine Sitemap ist eine Datei, in der Sie Informationen über die Seiten, Videos und andere Dateien auf Ihrer Website und die Beziehungen zwischen ihnen bereitstellen. Suchmaschinen wie Google lesen diese Datei, um Ihre Website intelligenter zu crawlen.

React hat keine eingebaute Möglichkeit, Sitemaps zu generieren. Wenn Sie etwas wie React Router verwenden, um das Routing zu handhaben, finden Sie Tools, die eine Sitemap generieren können, obwohl dies einige Mühe erfordern kann.

Andere SEO-Überlegungen

Diese Überlegungen beziehen sich auf die Einrichtung guter SEO-Praktiken im Allgemeinen.

1. Haben Sie eine optimale URL-Struktur, um Menschen und Suchmaschinen eine gute Vorstellung davon zu geben, was sie auf der Seite erwarten können.
2. Die Optimierung der robots.txt-Datei kann Such-Bots helfen zu verstehen, wie Seiten auf Ihrer Website gecrawlt werden.
3. Verwenden Sie ein CDN, um alle statischen Assets wie CSS, JS, Schriftarten usw. bereitzustellen, und verwenden Sie responsive Bilder, um die Ladezeiten zu verkürzen.

Wir können viele der oben beschriebenen Probleme lösen, indem wir serverseitiges Rendering (SSR) oder Pre-Rendering verwenden. Wir werden diese Ansätze im Folgenden überprüfen.

Geben Sie Isomorphe Reaktion ein

Die Wörterbuchdefinition von isomorph ist „entsprechend oder ähnlich in der Form“.

In React-Begriffen bedeutet dies, dass der Server eine ähnliche Form wie der Client hat. Mit anderen Worten, Sie können dieselben React-Komponenten auf dem Server und dem Client wiederverwenden.

Dieser isomorphe Ansatz ermöglicht es dem Server, die React-App zu rendern und die gerenderte Version an unsere Benutzer und Suchmaschinen zu senden, damit sie den Inhalt sofort sehen können, während JavaScript im Hintergrund geladen und ausgeführt wird.

Frameworks wie Next.js oder Gatsby haben diesen Ansatz populär gemacht. Wir sollten beachten, dass isomorphe Komponenten wesentlich anders aussehen können als herkömmliche React-Komponenten. Beispielsweise können sie Code enthalten, der auf dem Server statt auf dem Client ausgeführt wird. Sie können sogar API-Geheimnisse enthalten (obwohl der Servercode entfernt wird, bevor er an den Client gesendet wird).

Ein zu beachtender Punkt ist, dass diese Frameworks viel Komplexität abstrahieren, aber auch eine rechthaberische Art des Schreibens von Code einführen. Wir werden in diesem Artikel weiter auf die Leistungsnachteile eingehen.

Wir werden auch eine Matrixanalyse durchführen , um die Beziehung zwischen Renderpfaden und Website-Performance zu verstehen. Aber vorher gehen wir einige Grundlagen der Messung der Website-Performance durch.

Metriken für die Website-Leistung

Lassen Sie uns einige der Faktoren untersuchen, die Suchmaschinen verwenden, um Websites zu bewerten.

Abgesehen von der schnellen und genauen Beantwortung der Anfrage eines Benutzers sollte eine gute Website laut Google die folgenden Eigenschaften aufweisen:

• Es sollte schnell geladen werden.
• Benutzer sollten ohne allzu lange Wartezeiten auf Inhalte zugreifen können.
• Es sollte früh mit den Aktionen eines Benutzers interaktiv werden.
• Es sollte keine unnötigen Daten abrufen oder teuren Code ausführen, um zu verhindern, dass die Daten oder der Akku eines Benutzers entladen werden.

Diese Funktionen lassen sich ungefähr den folgenden Metriken zuordnen:

• TTFB : Time to First Byte – Die Zeit zwischen dem Klicken auf einen Link und dem ersten eingehenden Inhalt.
• LCP : Largest Contentful Paint – Der Zeitpunkt, an dem der angeforderte Artikel sichtbar wird. Google empfiehlt, diesen Wert unter 2,5 Sekunden zu halten.
• TTI : Time To Interactive – Die Zeit, zu der eine Seite interaktiv wird (ein Benutzer kann scrollen, klicken usw.).
• Paketgröße – Die Gesamtzahl der heruntergeladenen Bytes und des ausgeführten Codes, bevor die Seite vollständig sichtbar und interaktiv wurde.

Wir werden diese Metriken noch einmal durchgehen, um besser zu verstehen, wie sich verschiedene Rendering-Pfade auf jeden einzelnen von ihnen auswirken können.

Lassen Sie uns als Nächstes verschiedene Renderpfade verstehen, die React-Entwicklern zur Verfügung stehen.

Renderpfade

Wir können eine React-Anwendung im Browser oder auf dem Server rendern und unterschiedliche Ausgaben erzeugen.

Zwei Funktionen unterscheiden sich erheblich zwischen client- und serverseitig gerenderten Apps, nämlich Routing und Code-Splitting . Diese schauen wir uns im Folgenden genauer an.

Clientseitiges Rendern (CSR)

Clientseitiges Rendern ist der standardmäßige Renderpfad für eine React-SPA. Der Server stellt eine Shell-App bereit , die keinen Inhalt enthält. Sobald der Browser die enthaltenen JavaScript-Quellen herunterlädt, parst und ausführt, wird der HTML-Inhalt ausgefüllt oder gerendert .

Die Routing-Funktion wird von der Client- App verwaltet, indem der Browserverlauf verwaltet wird. Dies bedeutet, dass unabhängig davon, welche Route angefordert wurde, dieselbe HTML-Datei bereitgestellt wird und der Client seinen Ansichtsstatus aktualisiert, nachdem er gerendert wurde.

Code-Splitting ist relativ einfach. Sie können Ihren Code mithilfe dynamischer Importe oder React.lazy aufteilen, sodass nur die erforderlichen Abhängigkeiten basierend auf Route oder Benutzeraktionen geladen werden.

Wenn die Seite Daten vom Server abrufen muss, um Inhalte zu rendern – beispielsweise einen Blog-Titel oder eine Produktbeschreibung –, kann sie dies nur tun, wenn die relevanten Komponenten gemountet und gerendert sind.

Der Benutzer wird höchstwahrscheinlich ein Zeichen oder eine Anzeige „Daten werden geladen“ sehen, während die Website zusätzliche Daten abruft.

Clientseitiges Rendering mit Bootstrapped-Daten (CSRB)

Stellen Sie sich das gleiche Szenario wie CSR vor, aber anstatt Daten abzurufen, nachdem das DOM gerendert wurde, nehmen wir an, dass der Server relevante Daten gesendet hat, die in bereitgestelltem HTML gebootstrapped wurden.

Wir könnten einen Knoten einfügen, der etwa so aussieht:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

Und analysieren Sie es, wenn die Komponente bereitgestellt wird:

 var data = JSON.parse(document.getElementById('data').innerHTML);

Wir haben uns gerade einen Hin- und Rückweg zum Server erspart. Wir werden die Kompromisse gleich sehen.

Serverseitiges Rendering für statische Inhalte (SSRS)

Stellen Sie sich ein Szenario vor, in dem wir HTML spontan generieren müssen.

Zum Beispiel, wenn wir einen Online-Rechner erstellen und der Benutzer eine Abfrage der Art /calculate/34+15 (ohne URL-Escapezeichen) ausgibt. Wir müssen die Abfrage verarbeiten, das Ergebnis auswerten und mit generiertem HTML antworten.

Unser generierter HTML-Code hat eine recht einfache Struktur und wir brauchen React nicht, um das DOM zu verwalten und zu manipulieren, sobald der generierte HTML-Code bereitgestellt wurde.

Wir stellen also nur HTML- und CSS-Inhalte bereit. Sie können die renderToStaticMarkup Methode verwenden, um dies zu erreichen.

Das Routing wird vollständig vom Server gehandhabt, da er HTML für jedes Ergebnis neu berechnen muss, obwohl CDN-Caching verwendet werden kann, um Antworten schneller bereitzustellen. CSS-Dateien können auch vom Browser zwischengespeichert werden, um nachfolgende Seiten schneller zu laden.

Serverseitiges Rendern mit Rehydration (SSRH)

Stellen Sie sich das gleiche Szenario wie das oben beschriebene vor, aber dieses Mal brauchen wir eine voll funktionsfähige React-Anwendung auf dem Client.

Wir werden das erste Rendering auf dem Server durchführen und HTML-Inhalte zusammen mit den JavaScript-Dateien zurücksenden. React rehydriert das vom Server gerenderte Markup und die Anwendung verhält sich ab diesem Zeitpunkt wie eine CSR-Anwendung.

React bietet integrierte Methoden, um diese Aktionen auszuführen.

Die erste Anfrage wird vom Server verarbeitet und nachfolgende Renderings werden vom Client verarbeitet. Daher werden solche Apps als universelle React-Apps bezeichnet (die sowohl auf dem Server als auch auf dem Client gerendert werden). Der Code zur Handhabung des Routings kann auf Client und Server aufgeteilt (oder dupliziert) werden.

Code-Splitting ist auch etwas knifflig, da ReactDOMServer React nicht unterstützt. faul, also müssen Sie möglicherweise so etwas wie Loadable Components verwenden.

Es sollte auch beachtet werden, dass ReactDOMServer nur ein flaches Rendering durchführt. Mit anderen Worten, obwohl die Rendermethode für Ihre Komponenten aufgerufen wird, werden die Lebenszyklusmethoden wie „ componentDidMount “ nicht aufgerufen. Daher müssen Sie Ihren Code umgestalten, um Daten für Ihre Komponenten mit einer alternativen Methode bereitzustellen.

Hier kommen Frameworks wie NextJS ins Spiel. Sie kaschieren die mit Routing und Code-Splitting in SSRH verbundenen Komplexitäten und sorgen für ein reibungsloseres Entwicklererlebnis.

Dieser Ansatz führt zu gemischten Ergebnissen, wenn es um die Seitenleistung geht, wie wir gleich feststellen werden.

Vorab-Rendering für statische Inhalte (PRS)

Was wäre, wenn wir eine Webseite rendern könnten, bevor ein Benutzer sie anfordert? Dies könnte zur Erstellungszeit oder dynamisch erfolgen, wenn sich die Daten ändern.

Wir können den resultierenden HTML-Inhalt dann in einem CDN zwischenspeichern und viel schneller bereitstellen, wenn ein Benutzer ihn anfordert.

Dies wird als Pre-Rendering bezeichnet, bevor wir den Inhalt rendern, Pre-User-Anfrage. Dieser Ansatz kann für Blogs und E-Commerce-Anwendungen verwendet werden, da deren Inhalt typischerweise nicht von Daten abhängt, die vom Benutzer bereitgestellt werden.

Vorrendering mit Rehydration (PRH)

Möglicherweise möchten wir, dass unser vorgerenderter HTML-Code eine voll funktionsfähige React-App ist, wenn ein Client ihn rendert.

Nachdem die erste Anfrage bedient wurde, verhält sich die Anwendung wie eine Standard-React-App. Dieser Modus ähnelt dem oben beschriebenen SSRH in Bezug auf Routing- und Code-Splitting-Funktionen.

Leistungsmatrix

Der Moment, auf den Sie gewartet haben, ist endlich gekommen. Es ist Zeit für einen Showdown. Sehen wir uns an, wie sich jeder dieser Rendering-Pfade auf die Webleistungsmetriken auswirkt, und ermitteln Sie den Gewinner.

In dieser Matrix weisen wir jedem Rendering-Pfad eine Punktzahl zu, basierend darauf, wie gut er in einer Leistungsmetrik abschneidet.

Die Punktzahl reicht von 1 bis 5:

• 1 = Unbefriedigend
• 2 = Schlecht
• 3 = Moderat
• 4 = Gut
• 5 = Ausgezeichnet

Die zentralen Thesen

Pre-Rendering für statische Inhalte (PRS) führt zu leistungsstärksten Websites, während serverseitiges Rendering mit Hydratation (SSRH) oder clientseitiges Rendering (CSR) zu enttäuschenden Ergebnissen führen kann.

Es ist auch möglich, mehrere Ansätze für verschiedene Teile der Website zu übernehmen . Beispielsweise können diese Leistungsmetriken für öffentlich zugängliche Webseiten von entscheidender Bedeutung sein, damit sie effizienter indexiert werden können, während sie möglicherweise weniger wichtig sind, sobald sich ein Benutzer angemeldet hat und private Kontodaten sieht.

Jeder Renderpfad stellt Kompromisse dar, wo und wie Sie Ihre Daten verarbeiten möchten. Wichtig ist, dass ein Engineering-Team in der Lage ist, diese Kompromisse klar zu sehen und zu diskutieren und eine Architektur auszuwählen, die die Zufriedenheit ihrer Benutzer maximiert.

Weiterführende Literatur und Überlegungen

Obwohl ich versucht habe, die derzeit gängigen Techniken abzudecken, ist dies keine erschöpfende Analyse. Ich empfehle dringend, diesen Artikel zu lesen, in dem Entwickler von Google andere fortgeschrittene Techniken wie Streaming-Server-Rendering, trisomorphes Rendering und dynamisches Rendering (mit unterschiedlichen Antworten für Crawler und Benutzer) diskutieren.

Einige andere Faktoren, die Sie beim Erstellen inhaltsintensiver Websites berücksichtigen müssen, sind die Notwendigkeit eines guten Content-Management-Systems (CMS) für Ihre Autoren und die Möglichkeit, Vorschauen für soziale Medien einfach zu erstellen/zu ändern und Bilder für unterschiedliche Bildschirmgrößen zu optimieren.