Vue.js und SEO: So optimieren Sie reaktive Websites für Suchmaschinen und Bots

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Werden Websites, die mit reaktiven Frameworks erstellt wurden, von Google und anderen Suchmaschinen indexiert? Ist es obligatorisch, Pre-Rendering einzurichten, wie Ihre SEO-Berater vorschlagen? Oder sind sie falsch?

Reaktive JavaScript-Frameworks (wie React, Vue.js und Angular) sind in letzter Zeit voll im Trend, und es ist kein Wunder, dass sie aufgrund ihrer Flexibilität, Modularität und einfachen automatisierten Tests in immer mehr Websites und Anwendungen eingesetzt werden.

Diese Frameworks ermöglichen es, neue, bisher undenkbare Dinge auf einer Website oder App zu erreichen, aber wie schneiden sie in Bezug auf SEO ab? Werden die mit diesen Frameworks erstellten Seiten von Google indexiert? Da bei diesen Frameworks das gesamte – oder das meiste – Seiten-Rendering in JavaScript erfolgt (und der HTML-Code, der von Bots heruntergeladen wird, meistens leer ist), scheinen sie ein No-Go zu sein, wenn Sie möchten, dass Ihre Websites indiziert werden Suchmaschinen oder sogar von Bots im Allgemeinen geparst.

In diesem Artikel werde ich hauptsächlich über Vue.js sprechen, da es das Framework ist, das ich am häufigsten verwendet habe und mit dem ich direkte Erfahrungen in Bezug auf die Indizierung durch die Suchmaschinen bei Großprojekten habe, aber davon kann ich am meisten ausgehen Was ich behandeln werde, gilt auch für andere Frameworks.

Ersetzen von jQuery durch Vue.js

Wussten Sie, dass Sie Vue genauso in Ihr Projekt integrieren können wie jQuery – ohne dass ein Build-Schritt erforderlich ist? Lesen Sie einen verwandten Artikel →

Mehr nach dem Sprung! Lesen Sie unten weiter ↓

Einige Hintergrundinformationen zum Problem

Wie die Indizierung funktioniert

Damit Ihre Website von Google indexiert werden kann, muss sie von Googlebot (einer automatisierten Indexierungssoftware, die Ihre Website besucht und den Inhalt von Seiten in ihrem Index speichert) gecrawlt werden, indem sie Links auf jeder Seite folgt. Der Googlebot sucht auch nach speziellen Sitemap-XML-Dateien in Websites, um Seiten zu finden, die von Ihrer öffentlichen Website möglicherweise nicht korrekt verlinkt sind, und um zusätzliche Informationen darüber zu erhalten, wie oft sich die Seiten der Website ändern und wann sie zuletzt geändert wurden.

Ein bisschen Geschichte

Bis vor einigen Jahren (vor 2009) indexierte Google den Inhalt des HTML einer Website – mit Ausnahme aller von JavaScript erstellten Inhalte. Es war allgemeines SEO-Wissen, dass wichtige Links und Inhalte nicht mit JavaScript geschrieben werden sollten, da sie von Google nicht indexiert würden und die Website möglicherweise bestraft würde, da Google sie als „gefälschten Inhalt“ betrachten könnte, als ob der Eigentümer der Website dies versuchen würde Benutzern etwas anderes zu zeigen, als den Suchmaschinen angezeigt wurde, und zu versuchen, letztere zu täuschen.

Es war eine sehr gängige Praxis von Betrügern, viele SEO-freundliche Inhalte in das HTML einzufügen und sie beispielsweise in JavaScript zu verstecken. Google hat immer vor dieser Praxis gewarnt:

„Das Bereitstellen von anderen Inhalten durch den Googlebot, als ein normaler Benutzer sehen würde, wird als Cloaking betrachtet und würde gegen unsere Richtlinien für Webmaster verstoßen.“

Dafür könnten Sie bestraft werden. In einigen Fällen könnten Sie dafür bestraft werden, dass Sie verschiedenen Benutzeragenten auf der Serverseite unterschiedliche Inhalte bereitstellen, aber auch Inhalte per JavaScript wechseln, nachdem die Seite geladen wurde. Ich denke, das zeigt uns, dass Google seit langem Websites indexiert, die JavaScript ausführen – zumindest, um den endgültigen HTML-Code der Website (nach der JavaScript-Ausführung) und den rohen HTML-Code zu vergleichen, den es für seine Indizes analysiert hat. Aber der Googlebot führte JavaScript nicht die ganze Zeit aus, und Google verwendete den JavaScript-generierten Inhalt nicht zu Indizierungszwecken.

Angesichts der zunehmenden Verwendung von AJAX zur Bereitstellung dynamischer Inhalte auf Websites schlug Google dann ein „AJAX-Crawling-Schema“ vor, um Benutzern zu helfen, AJAX-basierte Websites zu indizieren. Es war sehr kompliziert; Es erforderte im Wesentlichen, dass die Website ein Rendering von Seiten mit enthaltenen AJAX-Inhalten erstellte. Auf Anfrage von Google würde der Server eine Version der Seite mit allen (oder den meisten) Inhalten bereitstellen, die dynamisch durch JavaScript in der HTML-Seite generiert worden wären – vorgerendert als HTML-Snapshot des Inhalts. Dieser Prozess, bei dem eine serverseitige Lösung Inhalte liefert, die (für alle anderen Zwecke) clientseitig generiert werden sollten, implizierte, dass diejenigen, die eine Website haben wollten, die sich stark auf JavaScript stützte, in Google indiziert waren technische Probleme.

Wenn beispielsweise der von AJAX gelesene Inhalt von einem externen Webdienst stammte, war es notwendig, dieselben Webdienstaufrufe serverseitig zu duplizieren und serverseitig denselben HTML-Code zu erzeugen, der clientseitig erzeugt worden wäre JavaScript – oder zumindest ein sehr ähnliches. Dies war sehr kompliziert, da es vor dem Aufkommen von Node.js erforderlich war, dieselbe Rendering-Logik zumindest teilweise in zwei verschiedenen Programmiersprachen zu duplizieren: JavaScript für das Frontend und PHP, Java, Python, Ruby und so weiter das Backend. Dies wird als „ serverseitiges Rendering “ bezeichnet und könnte zur Wartungshölle führen: Wenn Sie wichtige Änderungen an der Art und Weise vorgenommen haben, wie Sie Inhalte im Frontend rendern, müssen Sie diese Änderungen im Backend duplizieren.

Die einzige Alternative, um das Duplizieren der Logik zu vermeiden, bestand darin, Ihre eigene Website mit einem Browser zu parsen, der JavaScript ausführt, und die Endergebnisse auf Ihrem Server zu speichern und diese dem Googlebot bereitzustellen. Dies ähnelt in gewisser Weise dem, was jetzt als „ Pre-Rendering “ bezeichnet wird.

Google (mit seinem AJAX-Crawling-Schema) garantierte auch, dass Sie Strafen vermeiden würden, weil Sie in diesem Fall unterschiedliche Inhalte für den Googlebot und den Benutzer bereitstellen. Seit 2015 hat Google diese Praxis jedoch mit einem offiziellen Blog-Beitrag abgelehnt, der Website-Managern Folgendes mitteilte:

„Solange Sie den Googlebot nicht daran hindern, Ihre JavaScript- oder CSS-Dateien zu crawlen, sind wir heute im Allgemeinen in der Lage, Ihre Webseiten wie moderne Browser darzustellen und zu verstehen.“

Was uns das sagte, war nicht, dass der Googlebot plötzlich die Fähigkeit erlangt hatte, JavaScript beim Indizieren von Webseiten auszuführen, da wir wissen, dass er dies schon seit sehr langer Zeit tat (zumindest um nach gefälschten Inhalten und Betrug zu suchen). Stattdessen teilte es uns mit, dass das Ergebnis der JavaScript-Ausführung indiziert und in SERPs verwendet werden würde.

Dies scheint zu implizieren, dass wir uns keine Sorgen mehr darum machen müssen, Google serverseitig gerendertes HTML bereitzustellen. Wir sehen jedoch alle möglichen Tools für serverseitiges Rendering und Pre-Rendering, die für JavaScript-Frameworks verfügbar gemacht werden, es scheint, dass dies nicht der Fall ist. Auch im Umgang mit SEO-Agenturen bei großen Projekten scheint das Pre-Rendering als obligatorisch angesehen zu werden. Woher?

Wie indiziert Google tatsächlich Seiten, die mit Front-End-Frameworks erstellt wurden?

Das Experiment

Um zu sehen, was Google tatsächlich in Websites indexiert, die mit einem Frontend-Framework erstellt wurden, habe ich ein kleines Experiment gebaut. Es deckt nicht alle Anwendungsfälle ab, ist aber zumindest ein Mittel, um mehr über das Verhalten von Google herauszufinden. Ich habe eine kleine Website mit Vue.js erstellt und verschiedene Textteile unterschiedlich gerendert.

Die Inhalte der Website stammen aus der Beschreibung des Buches Infinite Jest von David Foster Wallace im Infinite Jest Wiki ( Danke Jungs! ). Es gibt ein paar einführende Texte für das ganze Buch und eine Liste von Charakteren mit ihrer individuellen Biografie:

  • Etwas Text im statischen HTML außerhalb des Vue.js-Hauptcontainers;
  • Einige Texte werden sofort von Vue.js gerendert, da sie in Variablen enthalten sind, die bereits im Code der Anwendung vorhanden sind: Sie sind im data der Komponente definiert;
  • #Einige Texte werden von Vue.js aus dem data gerendert, jedoch mit einer Verzögerung von 300 ms;
  • Das Charakter-Bios stammt aus einer Reihe von Rest-APIs, die ich absichtlich mit Sandbox erstellt habe. Da ich davon ausgegangen bin, dass Google den Code der Website ausführen und nach einiger Zeit anhalten würde, um einen Schnappschuss des aktuellen Zustands der Seite zu machen, habe ich jeden Webdienst so eingestellt, dass er mit einer inkrementellen Verzögerung reagiert, der erste mit 0 ms, der zweite mit 300 ms, die dritte mit 600ms und so weiter bis 2700ms.

Jede Charakterbiografie ist gekürzt und enthält einen Link zu einer Unterseite, die nur über Vue.js verfügbar ist (URLs werden von Vue.js mithilfe der History-API generiert), aber nicht serverseitig (wenn Sie die URL der Seite direkt, Sie erhalten keine Antwort vom Server), um zu prüfen, ob diese auch indiziert wurden. Ich bin davon ausgegangen, dass diese nicht indiziert werden, da es sich nicht um richtige Links handelt, die serverseitig gerendert werden, und es gibt keine Möglichkeit, dass Google Benutzer direkt zu diesen Links leiten kann. Aber ich wollte nur nachsehen.

Ich habe diese kleine Testseite auf meinen Github-Seiten veröffentlicht und um Indexierung gebeten – schau mal.

Die Ergebnisse

Die Ergebnisse des Experiments (bezüglich der Homepage) sind die folgenden:

  • Die Inhalte, die sich bereits im statischen HTML-Inhalt befinden, werden von Google indexiert (was ziemlich offensichtlich ist);
  • Die von Vue in Echtzeit generierten Inhalte werden immer von Google indexiert;
  • Die Inhalte, die von Vue generiert, aber nach 300 ms gerendert werden, werden ebenfalls indiziert;
  • Die Inhalte, die mit einiger Verzögerung vom Webdienst kommen, werden möglicherweise indiziert, aber nicht immer. Ich habe die Indexierung der Seite durch Google zu verschiedenen Zeitpunkten überprüft, und der zuletzt eingefügte Inhalt (nach ein paar Sekunden) wurde manchmal indexiert, manchmal nicht. Der Inhalt, der ziemlich schnell gerendert wird, wird meistens indiziert, selbst wenn er von einem asynchronen Aufruf an einen externen Webdienst stammt. Dies hängt davon ab, ob Google für jede Seite und Website ein Rendering-Budget hat, das von seinen internen Algorithmen abhängt, und es kann je nach Ranking Ihrer Website und dem aktuellen Status der Rendering-Warteschlange des Googlebot stark variieren. Sie können sich also nicht darauf verlassen, dass Inhalte von externen Webdiensten indexiert werden;
  • Die Unterseiten (da sie nicht als direkter Link erreichbar sind) werden nicht wie erwartet indexiert.

Was sagt uns dieses Experiment? Grundsätzlich gilt, dass Google dynamisch generierte Inhalte indexiert, auch wenn sie von einem externen Webservice stammen, aber es ist nicht garantiert, dass Inhalte indexiert werden, wenn sie „zu spät eintreffen“. Neben diesem Experiment habe ich ähnliche Erfahrungen mit anderen echten Produktionswebsites gemacht.

Wettbewerbsfähiges SEO

Okay, der Inhalt wird also indexiert , aber was dieses Experiment uns nicht sagt, ist: Wird der Inhalt wettbewerbsfähig eingestuft? Wird Google eine Website mit statischen Inhalten einer dynamisch generierten Website vorziehen? Diese Frage ist nicht leicht zu beantworten.

Aus meiner Erfahrung kann ich sagen, dass dynamisch generierte Inhalte in den Top-Positionen der SERPS ranken können. Ich habe an der Website für ein neues Modell eines großen Autoherstellers gearbeitet und eine neue Website mit einer neuen Third-Level-Domain gestartet. Die Seite wurde vollständig mit Vue.js generiert – mit sehr wenig Inhalt im statischen HTML neben <title> -Tags und meta -Beschreibungen.

Die Website begann in den ersten Tagen nach der Veröffentlichung mit dem Ranking für kleinere Suchanfragen, und die Textausschnitte in den SERPs meldeten Wörter, die direkt aus dem dynamischen Inhalt stammten.

Innerhalb von drei Monaten stand es bei den meisten Suchanfragen zu diesem Automodell an erster Stelle – was relativ einfach war, da es auf einer offiziellen Domain des Autoherstellers gehostet wurde und die Domain stark von seriösen Websites verlinkt war.

Aber angesichts der Tatsache, dass wir mit starkem Widerstand seitens des SEO-Unternehmens konfrontiert waren, das für das Projekt verantwortlich war, denke ich, dass das Ergebnis dennoch bemerkenswert ist.

Aufgrund der knappen Fristen und des Zeitmangels für das Projekt wollten wir die Seite ohne Pre-Rendering veröffentlichen.

Animierter Text

Was Google nicht indiziert, ist stark animierter Text. Die Website eines der Unternehmen, mit denen ich zusammenarbeite, Rabbit Hole Consulting, enthält viele Textanimationen, die ausgeführt werden, während der Benutzer scrollt, und erfordern, dass der Text in mehrere Abschnitte über verschiedene Tags aufgeteilt wird.

Die Haupttexte auf der Homepage der Website sind nicht für die Suchmaschinenindexierung gedacht, da sie nicht für SEO optimiert sind. Sie bestehen nicht aus Fachsprache und verwenden keine Schlagworte, sondern sollen den Benutzer lediglich auf einer gedanklichen Reise durch das Unternehmen begleiten . Der Text wird dynamisch eingefügt, wenn der Benutzer die verschiedenen Abschnitte der Startseite betritt.

Kaninchenbau-Beratung
(Bildquelle: Rabbit Hole Consulting) (Große Vorschau)

Keiner der Texte in diesen Bereichen der Website wird von Google indexiert. Damit Google etwas Sinnvolles in den SERPs anzeigt, haben wir in der Fußzeile unterhalb des Kontaktformulars statischen Text hinzugefügt, und dieser Inhalt wird als Teil des Seiteninhalts in den SERPs angezeigt.

Der Text in der Fußzeile wird indiziert und in SERPs angezeigt, obwohl er für die Benutzer nicht sofort sichtbar ist, es sei denn, sie scrollen zum Ende der Seite und klicken auf die Schaltfläche „Fragen“, um das Kontaktformular zu öffnen. Dies bestätigt meine Meinung, dass Inhalte indiziert werden, auch wenn sie dem Benutzer nicht sofort angezeigt werden, solange sie bald in HTML gerendert werden – im Gegensatz zu einer Rendering nach Bedarf oder mit langer Verzögerung.

Was ist mit Pre-Rendering?

Warum also all die Aufregung um das Pre-Rendering – sei es serverseitig oder zur Projektkompilierungszeit? Ist es wirklich notwendig? Obwohl einige Frameworks, wie Nuxt, die Ausführung viel einfacher machen, ist es immer noch kein Zuckerschlecken, daher ist die Entscheidung, ob man es einrichtet oder nicht, keine leichte.

Ich denke, es ist keine Pflicht . Dies ist sicherlich erforderlich, wenn viele der Inhalte, die Sie von Google indizieren lassen möchten, von einem externen Webdienst stammen und zum Zeitpunkt des Renderns nicht sofort verfügbar sind und – in einigen unglücklichen Fällen – beispielsweise aufgrund von überhaupt nicht verfügbar sein könnten , Ausfallzeit des Webdienstes. Wenn während der Besuche des Googlebots einige Ihrer Inhalte zu langsam ankommen, werden sie möglicherweise nicht indexiert . Wenn der Googlebot Ihre Seite genau zu einem Zeitpunkt indiziert, in dem Sie Wartungsarbeiten an Ihren Webdiensten durchführen, indexiert er möglicherweise überhaupt keine dynamischen Inhalte.

Außerdem habe ich keinen Beleg für Ranking -Unterschiede zwischen statischen Inhalten und dynamisch generierten Inhalten. Das könnte ein weiteres Experiment erfordern. Ich denke, dass es sehr wahrscheinlich ist, dass Inhalte, die von einem externen Webdienst stammen und nicht sofort geladen werden, sich auf die Wahrnehmung Ihrer Website durch Google auswirken können, was ein sehr wichtiger Faktor für das Ranking ist.

Empfohlene Lektüre : Wie sich mobiles Webdesign auf die lokale Suche auswirkt (und was man dagegen tun kann)

Andere Überlegungen

Kompatibilität

Bis vor kurzem verwendete der Googlebot eine ziemlich alte Version von Chromium (dem Open-Source-Projekt, auf dem Google Chrome basiert), nämlich Version 41. Dies führte dazu, dass einige neuere JavaScript- oder CSS-Funktionen von Google nicht korrekt wiedergegeben werden konnten (z. B. IntersectionObserver, ES6-Syntax usw.).

Google hat kürzlich angekündigt, dass es jetzt die neueste Version von Chromium (74, zum Zeitpunkt des Schreibens) im Googlebot ausführt und dass die Version regelmäßig aktualisiert wird. Die Tatsache, dass Google Chromium 41 ausführte, könnte große Auswirkungen auf Websites gehabt haben, die sich entschieden haben, die Kompatibilität mit IE11 und anderen alten Browsern zu ignorieren.

Sie können hier einen Vergleich der Unterstützung von Funktionen von Chromium 41 und Chromium 74 sehen. Wenn Ihre Website jedoch bereits fehlende Funktionen polyfilliert hat, um mit älteren Browsern kompatibel zu bleiben, sollte es kein Problem geben.

Verwenden Sie immer Polyfills , da Sie nie wissen, welcher Browser die Unterstützung für Funktionen vermisst, die Sie für alltäglich halten. Beispielsweise unterstützte Safari eine wichtige und sehr nützliche neue Funktion wie IntersectionObserver erst mit Version 12.1, die im März 2019 herauskam.

JavaScript-Fehler

Wenn Sie sich darauf verlassen, dass der Googlebot Ihr JavaScript ausführt, um wichtige Inhalte wiederzugeben, müssen schwerwiegende JavaScript-Fehler, die die Wiedergabe der Inhalte verhindern könnten, um jeden Preis vermieden werden. Während Bots möglicherweise HTML analysieren und indizieren, das nicht vollständig gültig ist (obwohl es immer vorzuziehen ist, auf jeder Website gültiges HTML zu haben!), Wenn es einen JavaScript-Fehler gibt, der das Laden einiger Inhalte verhindert , gibt es keine Möglichkeit, dass Google indexiert diesen Inhalt.

Wenn Sie sich auf JavaScript verlassen, um wichtige Inhalte für Ihre Endbenutzer bereitzustellen, haben Sie wahrscheinlich bereits umfangreiche Unit-Tests, um auf Blockierungsfehler jeglicher Art zu prüfen. Beachten Sie jedoch, dass Javascript-Fehler aus unvorhersehbaren Szenarien entstehen können, beispielsweise im Falle einer unsachgemäßen Behandlung von Fehlern in API-Antworten.

Es ist besser, eine Echtzeit-Fehlerprüfungssoftware (wie Sentry oder LogRocket) zu haben, die Sie auf Grenzfallfehler hinweist, die Sie während des Komponenten- oder manuellen Tests möglicherweise nicht erkennen. Dies erhöht die Komplexität des Vertrauens auf JavaScript für SEO-Inhalte.

Andere Suchmaschinen

Die anderen Suchmaschinen arbeiten mit dynamischen Inhalten nicht so gut wie Google. Bing scheint dynamische Inhalte überhaupt nicht zu indizieren, genau wie DuckDuckGo oder Baidu. Wahrscheinlich fehlen diesen Suchmaschinen die Ressourcen und die Rechenleistung, die Google im Überfluss hat.

Das Parsen einer Seite mit einem Headless-Browser und das Ausführen von JavaScript für ein paar Sekunden, um den gerenderten Inhalt zu parsen, ist sicherlich ressourcenintensiver, als nur einfaches HTML zu lesen. Oder vielleicht haben sich diese Suchmaschinen aus anderen Gründen entschieden, dynamische Inhalte nicht zu scannen. Was auch immer die Ursache dafür ist, wenn Ihr Projekt eine dieser Suchmaschinen unterstützen muss, müssen Sie das Pre-Rendering einrichten.

Hinweis : Weitere Informationen zu den Wiedergabefunktionen anderer Suchmaschinen finden Sie in diesem Artikel von Bartosz Goralewicz. Es ist schon etwas älter, aber meiner Erfahrung nach immer noch gültig.

Andere Bots

Denken Sie daran, dass Ihre Website auch von anderen Bots besucht wird. Die wichtigsten Beispiele sind Twitter, Facebook und andere Social-Media-Bots, die Metainformationen über Ihre Seiten abrufen müssen, um eine Vorschau Ihrer Seite anzuzeigen, wenn sie von ihren Benutzern verlinkt wird. Diese Bots indizieren keine dynamischen Inhalte und zeigen nur die Metainformationen an, die sie im statischen HTML finden. Dies führt uns zur nächsten Überlegung.

Unterseiten

Wenn Ihre Website eine sogenannte „One-Page-Website“ ist und sich alle relevanten Inhalte in einem Haupt-HTML befinden, können Sie diese Inhalte problemlos von Google indexieren lassen. Wenn Sie jedoch möchten, dass Google eine sekundäre Seite auf der Website indiziert und anzeigt, müssen Sie dennoch statisches HTML für jede dieser Seiten erstellen – selbst wenn Sie sich auf Ihr JavaScript-Framework verlassen, um die aktuelle URL zu überprüfen und den relevanten Inhalt bereitzustellen auf dieser Seite. Mein Rat ist in diesem Fall, serverseitige (oder statische) Seiten zu erstellen, die zumindest den richtigen title -Tag und die Meta-Beschreibung/Informationen enthalten.

Schlussfolgerungen

Die Schlussfolgerungen, zu denen ich bei der Recherche dieses Artikels gekommen bin, sind die folgenden:

  1. Wenn Sie nur auf Google abzielen, ist es jedoch nicht zwingend erforderlich, Pre-Rendering zu verwenden , damit Ihre Website vollständig indexiert wird:
  2. Sie sollten sich bei Inhalten, die indiziert werden müssen, nicht auf Webdienste von Drittanbietern verlassen, insbesondere wenn diese nicht schnell antworten.
  3. Der Inhalt, den Sie sofort über das Vue.js-Rendering in Ihr HTML einfügen , wird indiziert, aber Sie sollten keinen animierten Text oder Text verwenden, der nach Benutzeraktionen wie Scrollen usw. in das DOM eingefügt wird.
  4. Stellen Sie sicher, dass Sie auf JavaScript-Fehler testen, da diese dazu führen können, dass ganze Seiten/Abschnitte nicht indiziert werden oder Ihre Website überhaupt nicht indiziert wird.
  5. Wenn Ihre Website über mehrere Seiten verfügt , benötigen Sie dennoch eine gewisse Logik, um Seiten zu erstellen, die sich zwar auf dasselbe Front-End-Rendering-System wie die Startseite stützen, aber von Google als einzelne URLs indexiert werden können.
  6. Wenn Sie zwischen verschiedenen Seiten unterschiedliche Beschreibungen und Vorschaubilder für soziale Medien benötigen, müssen Sie dies ebenfalls angehen, entweder serverseitig oder durch Kompilieren statischer Seiten für jede URL.
  7. Wenn Sie möchten, dass Ihre Website in anderen Suchmaschinen als Google funktioniert , benötigen Sie auf jeden Fall eine Art Vorab-Rendering.