Was ist Prerendering?

Prerendering heißt, das HTML einer Seite zu erzeugen, bevor sie jemand anfordert — meist beim Bauen der Website — und es fertig auszuliefern. Wenn der erste Besuch kommt, ist die Arbeit getan, und es bleibt nichts auszuführen, um den Inhalt zu sehen.

Es ist eine unmittelbare Antwort auf das Problem, das JavaScript-SEO aufwirft: Erscheint alles Wichtige erst nach dem Ausführen des Codes, sieht jeder Leser, der ihn nicht ausführt oder später ausführt, eine unvollständige Seite.

Das Wort wird in zwei verschiedenen Weiten benutzt, und die gehören auseinander. Im SEO meint es meist die statische Erzeugung aller Seiten eines CMS; im Browser gibt es zusätzlich eine Funktion, die den wahrscheinlich nächsten Verweis vorlädt und vorrendert. Gleicher Name, verschiedener Zweck.

Es lohnt zu sagen, was sich NICHT ändert. Prerendering rührt weder am Inhalt noch an der internen Verlinkung: dieselbe Seite, dieselben Texte, dieselben Verweise. Verändert wird einzig der Zeitpunkt, zu dem dieses HTML existiert — und das genügt bereits, damit das Gespräch mit einer Suchmaschine ein anderes wird.

Es ist auch keine neue oder besonders raffinierte Technik. Bevor Websites im Browser gebaut wurden, waren alle Seiten vorher geschriebene Dateien; was wir Prerendering nennen, ist zu weiten Teilen die Rückkehr dorthin — mit Werkzeugen, die diese Dateien aus Vorlagen und Daten erzeugen.

Alle Bauweisen einer Website unterscheiden sich an einer einzigen Frage: zu welchem Zeitpunkt das HTML existiert. Beim Bauen der Website, bei jeder Anfrage, im Browser des Besuchers — oder unterschiedlich, je nachdem, wer fragt.

Die ersten drei sind berechtigte Entscheidungen mit verschiedenen Kosten. Die vierte verdient eine Anmerkung, weil sie jahrelang empfohlen wurde und heute nicht mehr: Google beschreibt sie als Behelf und nicht als Lösung auf Dauer und empfiehlt stattdessen serverseitiges Rendern, statisches Rendern oder Hydration.

Und es gehört nicht als Leiter von schlecht nach gut gelesen. Ein Blog, der sich wöchentlich ändert, und ein E-Commerce mit Live-Bestand haben nicht dieselbe richtige Antwort; gewählt wird, wo die Arbeit bezahlt wird, nicht wie viel Qualität man will.

Eine fünfte Form passt nicht in die Liste, weil sie zwei verbindet: vorab erzeugen und in Stapeln auffrischen, sobald sich etwas ändert. Das ist heute der verbreitetste Mittelweg, weil er die sofortige Auslieferung behält, ohne den Inhalt zum Einfrieren zu verurteilen.

Und es lohnt zu bemerken, wer jeweils entscheidet. Bei den ersten drei entscheidet das Team, das die Website baut; bei der vierten entscheidet der Server im Moment, indem er ansieht, wer fragt. Dieser Unterschied ist der eigentliche Grund, warum die letzte schlecht altert: Jede Änderung daran, woran ein Crawler erkannt wird, kann sie zerbrechen, ohne dass jemand den Code anfasst.

Es bringt Vorhersagbarkeit. Die Seite kommt für alle vollständig an, der Crawler sieht sie schon in der ersten Phase ganz, und der TTFB ist meist der bestmögliche, weil im Moment der Anfrage nichts zu berechnen ist.

Es kostet Frische. Ein gestern erzeugtes HTML sagt weiter, was gestern galt, bis es neu erzeugt wird — und das prallt frontal auf einen Katalog, dessen Preise und Verfügbarkeit sich über den Tag ändern und im Index die alte Fassung stehen bleibt.

Und ein Preis kommt mit der Größe: die Bauzeit. Hunderttausend Seiten bei jeder Veröffentlichung zu erzeugen ist nicht mehr umsonst, und ab einem gewissen Punkt zwingt es dazu, nur das Geänderte zu erzeugen — eine Architekturentscheidung, keine Einstellung.

Ein weniger offensichtlicher und ziemlich wertvoller Gewinn ist die Widerstandsfähigkeit. Eine bereits erzeugte Seite wird weiter ausgeliefert, auch wenn die Datenbank ausfällt, was sonst einen 500-Fehler ergäbe, der sie gebaut hat — in diesem Moment ist sie nicht mehr als eine Datei. Für kritische Bereiche wie Preise, Kontakt oder Rechtstexte wiegt das mehr als ein paar Zehntelsekunden.

Und ein Preis am anderen Ende: die Fehlersuche. Geht etwas schief, geschah der Fehler beim Bauen, also Stunden früher und auf einer anderen Maschine, nicht bei dem Besuch, der ihn aufdeckte. Brauchbar sind dort nicht die Protokolle des Servers, sondern die des Erzeugungslaufs — etwas, das man geregelt haben sollte, bevor man es braucht, wie bei der Logfile-Analyse.

Klar sinnvoll ist es, wenn sich der Inhalt seltener ändert als die Besuche eintreffen: Artikel, Leistungsseiten, Dokumentation, Glossare — alles, was ein Crawling eine Woche später unverändert vorfindet. Dort ist einmal erzeugen und tausendmal ausliefern schlicht die richtige Rechnung.

Sinnlos wird es, sobald jeder Besucher etwas anderes sehen muss — seinen Warenkorb, seine Sitzung, seine Preise —, denn das lässt sich nicht teilen. Der übliche Ausweg ist gemischt: der stabile Teil vorgerendert, das Persönliche getrennt nachgeladen. Das vermeidet zugleich das Problem, im CDN zu speichern, was dort nicht gespeichert gehört.

Und es gibt einen sehr häufigen Zwischenfall: Inhalt, der sich täglich ändert, aber nicht minütlich. Dort genügt es, in Stapeln oder bei erkannter Änderung neu zu erzeugen — und es lohnt, in der Logfile-Analyse nachzusehen, wie oft der Crawler tatsächlich wiederkommt, bevor man den Takt festlegt.

Ein praktisches Zeichen zur Entscheidung: Sieh nach, wie viele deiner URLs jedem Eintretenden genau dasselbe zeigen. Sind es die meisten — und auf den meisten Websites sind sie es —, ist Vorab-Erzeugen für diesen Teil die naheliegende Wahl, auch wenn der Rest etwas anderes braucht.

Und eine Vorsicht zur Größe: Wächst der Katalog, wächst die Bauzeit mit, und irgendwann zwingt eine kleine Änderung dazu, alles neu zu erzeugen. Bevor es so weit ist, sollte man nur das Betroffene erzeugen können — zumal wenn die Paginierung die URLs vervielfacht; das von Anfang an einzurichten ist leichter, als es umzubauen, wenn der E-Commerce bereits hunderttausend Produktseiten hat.

Der erste ist, nur für Suchmaschinen vorzurendern. Genau das ist das dynamische Rendern, von dem Google abrät, und es zwingt zusätzlich dazu, zwei Fassungen zu pflegen, die unbemerkt auseinanderlaufen.

Der zweite ist, das Neuerzeugen zu vergessen. Eine einmal erzeugte und nie wieder angefasste Seite friert ein: alte Preise, abgelaufene Hinweise, Verweise auf Bereiche, die es nicht mehr gibt und die in 404-Fehlern enden.

Und der dritte ist die Annahme, damit seien die Leistungsprobleme erledigt. Das HTML kommt früher an, aber wenn danach drei Megabyte Code geladen werden, stehen der INP und das Gefühl von Langsamkeit genau dort, wo sie vorher standen.

Ein vierter Fehler, typisch für Migrationen: vorrendern und die Header vergessen. Das HTML kommt tadellos an, doch die Anweisungen, die in der Antwort mitreisen — darunter das X-Robots-Tag —, hängen daran, WIE die Dateien ausgeliefert werden, nicht daran, wie sie erzeugt wurden. Beim Serverwechsel gehen sie leicht unbemerkt verloren.

Und der letzte: zu glauben, erzeugtes HTML sei allein deshalb gut. Ein Generator gibt getreu wieder, was man ihm sagt — auch ein falsch gesetztes Canonical oder einen Titel, der auf tausend Seiten wiederholt wird, also doppelten Content. Vorrendern beschleunigt die Auslieferung dessen, was da ist; es verbessert es nicht.