Clientseitiges Rendering von HTML und Interaktivität

Das Rendern von HTML mit JavaScript unterscheidet sich vom Rendern von HTML, das vom Server gesendet wird. Das kann sich auf die Leistung auswirken. In diesem Leitfaden erfahren Sie, worin der Unterschied besteht und was Sie tun können, um die Renderingleistung Ihrer Website zu erhalten, insbesondere bei Interaktionen.

Jeremy Wagner

Das Parsen und Rendern von HTML ist etwas, das Browser standardmäßig sehr gut für Websites erledigen, die die integrierte Navigationslogik des Browsers verwenden. Dies wird manchmal als „traditionelles Seitenladen“ oder „harte Navigation“ bezeichnet. Solche Websites werden manchmal als mehrseitige Anwendungen (Multi-Page Applications, MPAs) bezeichnet.

Entwickler können die Browserstandardeinstellungen jedoch an die Anforderungen ihrer Anwendung anpassen. Das ist auf jeden Fall bei Websites der Fall, die das SPA-Muster (Single Page Application) verwenden, bei dem große Teile des HTML/DOM dynamisch mit JavaScript auf dem Client erstellt werden. Dieses Designmuster wird als clientseitiges Rendering bezeichnet und kann sich auf die Interaktion bis zur nächsten Darstellung (Interaction to Next Paint, INP) Ihrer Website auswirken, wenn der Aufwand zu hoch ist.

In diesem Leitfaden erfahren Sie, wie sich die Verwendung von HTML, das vom Server an den Browser gesendet wird, von der Erstellung auf dem Client mit JavaScript unterscheidet und wie Letzteres in kritischen Momenten zu einer hohen Interaktionslatenz führen kann.

So rendert der Browser vom Server bereitgestellte HTML-Dateien

Beim Navigationsmuster, das bei herkömmlichen Seitenladevorgängen verwendet wird, wird bei jeder Navigation HTML vom Server empfangen. Wenn du eine URL in die Adressleiste deines Browsers eingibst oder auf einen Link in einer MPA klickst, geschieht Folgendes:

1. Der Browser sendet eine Navigationsanfrage für die angegebene URL.
2. Der Server antwortet mit HTML-Chunks.

Der letzte Schritt ist entscheidend. Es ist auch eine der grundlegendsten Leistungsoptimierungen bei der Server-/Browser-Austauschkommunikation und wird als Streaming bezeichnet. Wenn der Server so schnell wie möglich mit dem Senden von HTML beginnen kann und der Browser nicht auf das Eintreffen der gesamten Antwort wartet, kann der Browser HTML in Teilen verarbeiten, sobald es eintrifft.

Wie bei den meisten Vorgängen im Browser erfolgt auch das Parsen von HTML innerhalb von Aufgaben. Wenn HTML vom Server an den Browser gestreamt wird, optimiert der Browser das Parsen dieses HTML, indem er es nach und nach vornimmt, da die Bits dieses Streams in Chunks ankommen. Das hat zur Folge, dass der Browser nach der Verarbeitung jedes Chunks regelmäßig den Hauptthread freigibt, wodurch lange Aufgaben vermieden werden. Das bedeutet, dass während des Parsens von HTML andere Aufgaben ausgeführt werden können, einschließlich des inkrementellen Renderings, das erforderlich ist, um eine Seite für den Nutzer anzuzeigen, sowie der Verarbeitung von Nutzerinteraktionen, die während der wichtigen Startphase der Seite auftreten können. Dadurch wird der Wert für Interaction to Next Paint (INP) für die Seite verbessert.

Das bedeutet: Wenn Sie HTML vom Server streamen, erhalten Sie kostenlos ein inkrementelles Parsen und Rendern von HTML und eine automatische Übergabe an den Hauptthread. Das ist beim clientseitigen Rendering nicht der Fall.

So rendert der Browser von JavaScript bereitgestellte HTML-Inhalte

Für jede Navigationsanfrage an eine Seite muss vom Server eine gewisse Menge an HTML bereitgestellt werden. Einige Websites verwenden jedoch das SPA-Muster. Bei diesem Ansatz wird vom Server häufig eine minimale anfängliche HTML-Nutzlast bereitgestellt, der Client füllt dann aber den Hauptinhaltsbereich einer Seite mit HTML aus, das aus Daten zusammengestellt wird, die vom Server abgerufen wurden. Nachfolgende Navigationen, die in diesem Fall manchmal als „weiche Navigationen“ bezeichnet werden, werden vollständig von JavaScript verarbeitet, um die Seite mit neuer HTML zu füllen.

Das clientseitige Rendering kann auch in nicht-SPAs in begrenzten Fällen auftreten, wenn HTML dem DOM über JavaScript dynamisch hinzugefügt wird.

Es gibt einige gängige Möglichkeiten, HTML zu erstellen oder dem DOM über JavaScript hinzuzufügen:

1. Mit der innerHTML-Eigenschaft können Sie den Inhalt eines vorhandenen Elements über einen String festlegen, der vom Browser in das DOM geparst wird.
2. Mit der Methode document.createElement können Sie neue Elemente erstellen, die dem DOM hinzugefügt werden, ohne dass das HTML des Browsers geparst wird.
3. Mit der document.write-Methode können Sie HTML in das Dokument schreiben. Der Browser analysiert es dann genau wie bei Ansatz 1. Aus verschiedenen Gründen wird jedoch von der Verwendung von document.write dringend abgeraten.

Die Folgen der Erstellung von HTML/DOM über clientseitiges JavaScript können erheblich sein:

• Im Gegensatz zu HTML, das vom Server als Reaktion auf eine Navigationsanfrage gestreamt wird, werden JavaScript-Aufgaben auf dem Client nicht automatisch in kleinere Teile aufgeteilt. Dies kann zu langen Aufgaben führen, die den Hauptthread blockieren. Das bedeutet, dass sich die INP Ihrer Seite negativ auswirken kann, wenn Sie auf dem Client zu viel HTML/DOM gleichzeitig erstellen.
• Wenn HTML beim Start auf dem Client erstellt wird, werden die darin referenzierten Ressourcen nicht vom Browser-Preload-Scanner erkannt. Das wirkt sich auf jeden Fall negativ auf den Largest Contentful Paint (LCP) einer Seite aus. Dies ist zwar kein Laufzeitleistungsproblem, sondern ein Netzwerkverzögerungsproblem beim Abrufen wichtiger Ressourcen. Sie sollten jedoch nicht zulassen, dass sich die LCP Ihrer Website durch Umgehung dieser grundlegenden Browserleistungsoptimierung verschlechtert.

Was Sie gegen die Leistungsauswirkungen des clientseitigen Renderings tun können

Wenn Ihre Website stark vom clientseitigen Rendering abhängt und Sie schlechte INP-Werte in Ihren Felddaten festgestellt haben, fragen Sie sich möglicherweise, ob das clientseitige Rendering etwas mit dem Problem zu tun hat. Wenn Ihre Website beispielsweise eine SPA ist, können Ihre Felddaten Interaktionen aufzeigen, die für erhebliche Rendering-Arbeiten verantwortlich sind.

Unabhängig von der Ursache findest du hier einige mögliche Ursachen, die du untersuchen kannst, um die Probleme zu beheben.

So viel HTML wie möglich vom Server bereitstellen

Wie bereits erwähnt, verarbeitet der Browser standardmäßig HTML-Code vom Server sehr effizient. Das Parsing und Rendering von HTML wird so aufgeteilt, dass lange Aufgaben vermieden und die Gesamtzeit des Hauptthreads optimiert wird. Dies führt zu einer kürzeren gesamten Blockierzeit. Die Gesamte Blockierzeit ist stark mit der INP korreliert.

Möglicherweise verwenden Sie ein Frontend-Framework, um Ihre Website zu erstellen. In diesem Fall sollten Sie das HTML der Komponenten auf dem Server rendern. Dadurch wird das anfängliche clientseitige Rendering Ihrer Website eingeschränkt, was sich positiv auf die Nutzerfreundlichkeit auswirken sollte.

• Bei React sollten Sie die Server DOM API verwenden, um HTML auf dem Server zu rendern. Beachten Sie jedoch, dass die traditionelle Methode des serverseitigen Renderings einen synchronen Ansatz verwendet, was zu einer längeren Zeit bis zum ersten Byte (TTFB) sowie zu nachfolgenden Messwerten wie First Contentful Paint (FCP) und LCP führen kann. Verwende nach Möglichkeit die Streaming-APIs für Node.js oder andere JavaScript-Laufzeiten, damit der Server so schnell wie möglich mit dem Streamen von HTML-Code an den Browser beginnen kann. Next.js ist ein React-basiertes Framework, das standardmäßig viele Best Practices bietet. Neben dem automatischen Rendern von HTML auf dem Server kann es auch statisches HTML für Seiten generieren, die sich nicht je nach Nutzerkontext ändern (z. B. Authentifizierung).
• Bei Vue wird standardmäßig auch clientseitiges Rendering durchgeführt. Wie React kann auch Vue Ihre Komponenten-HTML auf dem Server rendern. Nutzen Sie nach Möglichkeit diese serverseitigen APIs oder ziehen Sie eine abstrahiertere Lösung für Ihr Vue-Projekt in Betracht, um die Best Practices leichter umzusetzen.
• In Svelte wird HTML standardmäßig auf dem Server gerendert. Wenn Ihr Komponentencode jedoch Zugriff auf browserspezifische Namespaces wie window benötigt, können Sie das HTML dieser Komponente möglicherweise nicht auf dem Server rendern. Prüfen Sie nach Möglichkeit alternative Ansätze, damit nicht unnötig clientseitig gerendert wird. SvelteKit ist für Svelte, was Next.js für React ist. Es bietet so viele Best Practices wie möglich für Ihre Svelte-Projekte, damit Sie potenzielle Fallstricke in Projekten vermeiden können, in denen nur Svelte verwendet wird.

Anzahl der auf dem Client erstellten DOM-Knoten begrenzen

Je größer das DOM ist, desto mehr Verarbeitung ist für das Rendern erforderlich. Unabhängig davon, ob Ihre Website eine vollwertige SPA ist oder neue Knoten als Folge einer Interaktion für eine MPA in ein vorhandenes DOM eingefügt werden, sollten Sie diese DOMs so klein wie möglich halten. Dadurch wird der Aufwand beim clientseitigen Rendering zur Anzeige dieser HTML-Datei reduziert, was sich hoffentlich positiv auf die INP Ihrer Website auswirkt.

Worker-Architektur für einen Streamingdienst

Dies ist eine fortgeschrittene Technik, die nicht für jeden Anwendungsfall geeignet ist. Mit ihr lässt sich Ihre MPA jedoch in eine Website verwandeln, die den Eindruck erweckt, dass sie sofort geladen wird, wenn Nutzer von einer Seite zur nächsten wechseln. Sie können einen Service Worker verwenden, um die statischen Teile Ihrer Website in CacheStorage vorab zu cachen, während Sie mit der ReadableStream API den Rest der HTML-Seite vom Server abrufen.

Wenn Sie diese Methode erfolgreich anwenden, wird kein HTML auf dem Client erstellt. Durch das sofortige Laden von Inhaltsteilen aus dem Cache entsteht jedoch der Eindruck, dass Ihre Website schnell geladen wird. Websites, die diesen Ansatz verwenden, können fast wie eine SPA wirken, aber ohne die Nachteile des clientseitigen Renderings. Außerdem wird die Menge an HTML reduziert, die Sie vom Server anfordern.

Kurz gesagt: Eine Streaming-Service Worker-Architektur ersetzt nicht die integrierte Navigationslogik des Browsers, sondern ergänzt sie. Weitere Informationen dazu, wie Sie dies mit Workbox erreichen, finden Sie im Hilfeartikel Schnellere mehrseitige Anwendungen mit Streams.

Fazit

Wie Ihre Website HTML empfängt und rendert, wirkt sich auf die Leistung aus. Wenn Sie sich darauf verlassen, dass der Server den gesamten (oder den Großteil) des für die Funktion Ihrer Website erforderlichen HTML-Codes sendet, erhalten Sie viele Vorteile: Inkrementelles Parsen und Rendern sowie automatisches Übergeben an den Hauptthread, um lange Aufgaben zu vermeiden.

Das clientseitige HTML-Rendering führt zu einer Reihe potenzieller Leistungsprobleme, die in vielen Fällen vermieden werden können. Aufgrund der Anforderungen der einzelnen Websites ist dies jedoch nicht immer zu 100% möglich. Um die potenziell langen Aufgaben zu vermeiden, die durch übermäßiges Rendern auf dem Client entstehen können, sollten Sie nach Möglichkeit so viel HTML Ihrer Website wie möglich vom Server senden, die DOM-Größe für HTML, das auf dem Client gerendert werden muss, so klein wie möglich halten und alternative Architekturen in Betracht ziehen, um die Bereitstellung von HTML für den Client zu beschleunigen und gleichzeitig das inkrementelle Parsen und Rendern des Browsers für vom Server geladenes HTML zu nutzen.

Wenn Sie das clientseitige Rendering Ihrer Website so gering wie möglich halten, verbessern Sie nicht nur den INP Ihrer Website, sondern auch andere Messwerte wie LCP, TBT und in einigen Fällen möglicherweise sogar die TTFB.

Hero-Image von Unsplash, von Maik Jonietz