Rendering und Auslieferung

Rendering und Auslieferung

0:00 Die Frage lautet nicht, ob serverseitig gerendert wird. Sie lautet: für welche Route? Und die Antwort fällt je Seite anders aus. Das ist die wichtigste Nachricht dieses Moduls, denn in vielen Projekten wird diese Entscheidung einmal für die ganze Anwendung getroffen — meistens am ersten Tag, meistens ohne Kriterien. Angular bietet drei Modi an und erlaubt ausdrücklich, sie zu mischen. In diesem Modul lernen Sie, wonach Sie je Route entscheiden.

Rendering, Performance und Sicherheit

0:27 Der fünfte Tag hat drei Themen, die eines gemeinsam haben: Bei allen dreien ist Messen wichtiger als Meinen. Heute Morgen die Auslieferung, dann Performance, nachmittags Sicherheit. Alles drei Bereiche, in denen sich Annahmen besonders hartnäckig halten.

Rendering-Arten unterscheiden

0:44 Beginnen wir mit den drei Modi. Der Unterschied liegt in einer einzigen Frage: Wann entsteht das HTML? Angular bietet gemischtes Rendering. Im Client-Modus entsteht die Seite im Browser. Im Server-Modus bei jeder Anfrage auf dem Server. Und beim Vorrendern beim Bauen, als statische Datei. Festgelegt wird das je Route in einer eigenen Konfigurationsdatei.

1:07 Denken Sie an eine Bäckerei: Vorrendern heißt, am Morgen alles backen und ins Regal legen. Server-Modus heißt, auf Bestellung backen. Client-Modus heißt, dem Kunden die Zutaten und den Ofen zu geben. Die dritte Spalte ist die, auf die es ankommt — sie nennt den Anwendungsfall, nicht die Technik. Angemeldete Arbeitsbereiche im Client-Modus, weil dort weder Suchmaschine noch erster Eindruck zählen.

1:32 Personalisierte, aktuelle Inhalte auf dem Server, weil sie zum Zeitpunkt der Anfrage entstehen müssen. Öffentliche, selten geänderte Seiten vorgerendert, weil sie sich nicht zwischen zwei Builds ändern. Wenn Sie eine Route nicht zuordnen können, liegt es meistens daran, dass sie zwei Dinge gleichzeitig ist — und dann lohnt es sich, sie zu teilen.

1:53 Vier Zeilen, drei verschiedene Modi — und genau das ist die Botschaft. Die öffentliche Standortseite wird vorgerendert, die Auftragsansichten laufen im Browser, der Rest auf dem Server. Worauf es ankommt: Das ist eine fachliche Entscheidung in technischer Form. Jede dieser Zeilen lässt sich in einem Satz begründen, und wenn nicht, wurde sie geraten.

2:14 Registriert wird die Liste beim Einrichten des Serverrenderings — das steht in der Fußzeile. Der erste Punkt ist der, den ich eingangs genannt habe: Ein Modus wird für die ganze Anwendung gewählt statt je Route. Meistens Server-Modus, weil er am mächtigsten klingt. Der zweite ist ein Datenschutzproblem mit Ansage: Eine personalisierte Seite wird vorgerendert und zeigt fremde Daten — vorgerendert heißt ja, einmal gebaut und für alle gleich.

2:40 Und der dritte ist der, der erst nach der Entscheidung auffällt: Der Betriebsaufwand des Servermodus. Sie brauchen dann einen laufenden Prozess, nicht nur einen Dateiserver.

Den passenden Modus je Route wählen

2:51 Jetzt zu den Kriterien. Drei Fragen, und danach ist die Zuordnung in den meisten Fällen eindeutig. Öffentliche Seiten ohne Personalisierung gewinnen durch Vorrendern: schnellste Auslieferung, kein Server zur Laufzeit. Personalisierte, aber öffentlich erreichbare Seiten profitieren vom Servermodus. Und hinter der Anmeldung, wo weder Suchmaschine noch erster Eindruck zählen, genügt clientseitiges Rendering.

3:16 Der letzte Punkt überrascht manche: Für einen Arbeitsbereich, in dem jemand acht Stunden am Tag arbeitet, ist die erste halbe Sekunde ziemlich egal. Für eine öffentliche Seite ist sie alles. Fünf Schritte, drei Fragen und eine Probe. Öffentlich erreichbar? Wie aktuell? Je Nutzer verschieden? Daraus folgt der Modus fast von allein.

3:36 Und dann kommt Schritt fünf, den man gern auslässt: das ausgelieferte Ergebnis im Quelltext gegenprüfen. Die Fußzeile sagt, warum — was im gelieferten HTML nicht steht, hilft weder der Suchmaschine noch dem ersten Eindruck. Das ist ein Ein-Zeilen-Test mit einem Abruf über die Kommandozeile, und er beantwortet die Frage endgültig.

3:58 Der erste Punkt ist eine teure Fehlentscheidung: Serverseitiges Rendering, obwohl alles hinter der Anmeldung liegt. Dann zahlen Sie Betriebsaufwand für einen Vorteil, den niemand hat. Der zweite ist das Gegenstück: Vorrendern gewählt, und der Inhalt veraltet zwischen zwei Builds — bei Öffnungszeiten ist das egal, bei Preisen nicht.

4:17 Und der dritte ist der, gegen den Schritt fünf gebaut ist: Die Annahme wird nie am ausgelieferten HTML überprüft. Man glaubt, es funktioniert, und niemand hat nachgesehen.

Hydration, Event Replay und Incremental Hydration

4:28 Kommen wir zu dem, was passiert, nachdem das HTML angekommen ist. Denn sichtbar ist nicht dasselbe wie bedienbar. Hydration übernimmt das vom Server gelieferte HTML, statt es zu verwerfen und neu aufzubauen — das spart nicht nur Arbeit, es vermeidet auch das Flackern. Event Replay merkt sich Eingaben, die vor der Bedienbarkeit geschehen, und spielt sie danach ab.

4:51 Und Incremental Hydration, seit Angular 20 stabil, aktiviert Bereiche schrittweise, gesteuert über die Auslöser an aufgeschobenen Blöcken. Das Grundproblem, das alle drei adressieren: Die Seite ist da, aber sie reagiert noch nicht. Vier Stationen, und der Abstand zwischen der ersten und der letzten ist das, worum es geht. Der Benutzer sieht die Seite nach Station eins. Bedienbar ist sie nach Station vier.

5:15 Auf einem schnellen Rechner liegt dazwischen vielleicht eine Zehntelsekunde — auf einem Werkstattrechner mit schlechter Verbindung durchaus zwei Sekunden. Und in diesen zwei Sekunden klickt der Benutzer, weil die Seite ja fertig aussieht. Station drei ist deshalb keine Feinheit, sondern der Unterschied zwischen funktioniert und funktioniert nicht.

5:35 Vier Punkte, und der zweite ist der, den jeder von uns schon erlebt hat: Ein früher Klick geht verloren, und der Benutzer klickt erneut. Bei einem Kaufen-Knopf wird das teuer — dann ist der Auftrag zweimal drin. Der dritte ist der sichtbare: Der Aufbau flackert, weil das gelieferte HTML verworfen und neu gebaut wird. Und der vierte beschreibt, warum Incremental Hydration existiert: Große Seiten sind lange sichtbar und lange unbedienbar, obwohl der Benutzer nur einen kleinen Teil davon braucht.

6:05 Der erste Punkt ist der häufigste Fehler beim Einführen von Serverrendering: Hydration scheitert, weil der Server anderes HTML erzeugt, als der Browser erwartet — typischerweise, weil irgendwo ein Zufallswert oder ein Zeitstempel drinsteckt. Der zweite ist der eben besprochene: Event Replay fehlt, frühe Eingaben verschwinden ohne Rückmeldung.

6:24 Und der dritte ist eine verpasste Gelegenheit: Alle Bereiche werden gleichzeitig aktiviert, obwohl nur einer sichtbar ist.

Server- und Browserumgebung trennen

6:31 Bleibt der praktische Teil, an dem die meisten Umstellungen zuerst scheitern: Auf dem Server gibt es keinen Browser. Serverseitig gerenderter Code läuft ohne Browser-Schnittstellen. Kein Fenster, kein Dokument, kein lokaler Speicher. Zugriffe darauf gehören in einen Rückruf, der nur im Browser läuft. Geheimnisse bleiben auf dem Server — das ist derselbe Gedanke wie in Modul zwei, nur von der anderen Seite.

6:56 Und ein praktisches Detail: Antworten des Datenzugriffs werden zwischen Server und Browser übertragen, damit derselbe Abruf nicht zweimal läuft. Das spart eine Anfrage je Seitenaufruf. Ein kleines Muster mit klarer Wirkung. Der Rückruf läuft ausschließlich im Browser; auf dem Server wird er nicht ausgeführt. Worauf es ankommt: Der Zugriff auf die Elementgröße steht nicht im Konstruktor.

7:20 Genau das war in Spurweite der Fehler, der den Vorrender-Lauf abgebrochen hat — eine einzige Zeile, die auf dem Entwicklungsrechner immer funktioniert hatte, weil es dort ja einen Browser gibt. Solche Stellen findet man nicht durch Nachdenken, sondern indem man den Serverlauf einmal ausführt. Der erste Punkt ist der eben beschriebene: Ein Zugriff auf das Browserfenster steht im Konstruktor und bricht den Serverlauf.

7:44 Der zweite ist derselbe Fehler in fremdem Code, und der ist unangenehmer: Eine Bibliothek greift intern auf das Dokument zu, und Sie merken es erst im Betrieb. Und der dritte ist ein Sicherheitsproblem, das leicht übersehen wird: Ein Geheimnis wandert über die Übertragung der Antworten in den Browser — der Server hatte es, die Antwort trug es mit, und jetzt steht es im ausgelieferten HTML.

Übung

8:07 Zwei Routen, zwei Entscheidungen — und eine Probe am tatsächlichen Ergebnis. Spurweite hat eine öffentliche Standortseite mit Adressen und Öffnungszeiten und eine angemeldete Auftragsübersicht. Beide wurden bisher gleich behandelt: alles im Browser gerendert. Die Folge — die Standortseite taucht in keiner Suche auf. Wer bei Falkenhorst nach einer Werkstatt in seiner Nähe sucht, findet die Seite nicht, weil im ausgelieferten HTML nur ein leeres Wurzelelement steht.

8:35 Das ist kein technisches Problem, das ist ein geschäftliches. Das Lernziel nennt beide Hälften: einen Modus aus Inhalt, Aktualität und Zugriffsschutz herleiten — und die Annahme am Ergebnis prüfen. Das Erfolgskriterium verlangt für beide Routen eine begründete Entscheidung, eine davon umgesetzt, und das ausgelieferte HTML als Beleg.

8:55 Der Beleg ist der Teil, der die Übung von einer Meinungsäußerung unterscheidet. Wer früh fertig ist, prüft, welche Browser-Zugriffe im Serverlauf scheitern würden — das ist oft eine überraschende Liste. Fünf Schritte, und die ersten beiden sind reine Denkarbeit: einordnen und begründen, je einen Satz. Schritt drei setzt eine Route um — nur eine, damit Zeit für Schritt vier bleibt.

9:20 Und der ist der eigentliche Kern: das ausgelieferte HTML im Quelltext prüfen. Suchen Sie nach dem Namen eines Standorts. Ist er da, hat die Umstellung gewirkt. Ist er nicht da, haben Sie etwas gelernt. Beides ist in Ordnung, nur Nichtnachsehen ist es nicht. Der erste Punkt ist die Bequemlichkeit, gegen die dieses ganze Modul geschrieben ist: Beide Routen bekommen denselben Modus, weil es einfacher ist.

9:45 Der zweite ist der, der die Übung entwertet: Die Entscheidung wird nicht am gelieferten HTML überprüft. Und der dritte ist eine Unvollständigkeit in der Begründung: Der Betriebsaufwand des Servermodus bleibt unerwähnt. Im nächsten Modul geht es um Performance — und dort gilt dieselbe Regel noch strenger: erst messen, dann ändern.