Webseiten mit Blazor Server (Teil 1)

Warum Blazor?

Als ich im Herbst 2022 die scotec Software Solutions AB gründete, stand ich vor der Wahl, mit welcher Technologie ich die Webseite des Unternehmens erstelle. Naheliegend war natürlich zunächst ein Content Management System, wie z.B. Word Press oder Typo3, einzusetzen. Hier kann man bereits mit relativ wenig Aufwand sehr gute Ergebnisse erzielen. Die Webseite mit HTML und JavaScript zu erstellen war für mich ebenfalls eine gute Alternative. Gibt es hier doch zahlreiche Frameworks und unzählige Bibliotheken. Damit sollte eine neue Website doch ebenfalls schnell erstellt sein.

Blazor stand zunächst weiter hinten auf meiner Liste, ausschlaggebend für meine Entscheidung waren dann jedoch meine natürliche Neugier auf neue Technologien sowie meine sehr guten Erfahrungen mit .NET, ASP.NET und der Programmiersprache C#. Seit dem Erscheinen von .NET 1.1 im Jahre 2003 bin ich ein großer Fan hiervon und meine Begeisterung hat nie nachgelassen.

Im ersten Teil dieses Artikels möchte ich zunächst auf die Fragen zu den Ladezeiten, zur Komplexität von Blazor-Anwendungen sowie zur Performance eingehen. Im zweiten Teil beantworte ich dann die Fragen zum Ressourcenverbrauch, zur Skalierung und zum Einsatz von JavaScript in Blazor-Anwendungen.

Sind die Ladezeiten von Blazor Anwendungen nicht zu groß?

Blazor ist ein Framework zur Erstellung interaktiver Web-Anwendungen mit C#. Blazor unterstützt sowohl das Hosting von serverseitigen Razor-Komponenten in ASP.NET Core Anwendungen (Blazor Server) als auch die Erstellung von Single Page Apps (SPAs), welche direkt im Browser ausgeführt werden (Blazor WebAssembly).

Um die erste Frage zu beantworten, müssen wir zunächst die grundlegenden Unterschiede zwischen Blazor Server und Blazor WebAssembly (WASM) betrachten. Sowohl mit Blazor Server als auch mit WASM lassen sich sogenannte Single Page Applications (SPA) erstellen. SPAs sind Webanwendungen, in denen bei Änderungen nur einzelne Teile einer Seite aktualisiert werden, anstatt immer die komplette Seite neu vom Server anzufordern.

Blazor WebAssemblies nutzen dazu die Fähikeiten moderner Browser, binär-Code auszuführen und somit die Inhalte der Webseite selbst zu rendern. Dazu muss jedoch das gesamte WebAssembly in Form von IL Code (.Net Intermediate Langugae) zusammmen mit der .NET Laufzeitumgebung vom Server geladen und anschließend auf dem Client "Just in Time" (JiT) kompiliert werden. Entsprechend lang ist die Wartezeit bis zur Darstellung der ersten Inhalte im Browser. WebAssemblies bieten sich beispielsweise zur Erstellung von Konfiguratoren an, welche von Ihrer Webseite geladen werden sollen. Anwender tolerieren wesentlich längere Ladezeiten, wenn Sie sich bereits auf Ihrer Webseite befinden.

Seit der .NET Version 6.0 unterstützt Blazor auch die Ahead-of-time (AOT) Kompilierung. Die daraus resultierenden WebAssemblies sind etwas größer als die entsprechenden IL-Dateien, was zu etwas längeren Ladezeit führt. AOT kompilierte WebAssembies bringen dafür jedoch eine weit bessere Performance bei der Ausführung mit sich und werden zudem im Browser-Cache zwischengespeichert. Ab dem zweiten Aufruf der Anwendung sind daher keine Verzögerungen mehr spürbar.

Die Akzeptanz der Anwender ist entscheidend für den Erfolg einer Webseite. Daher kommt es bei einer öffentlichen Unternehmensseiten, aber auch bei internen Anwendungen, auf möglichst kurze Ladezeiten an. Idealerweise betragen diese weniger als eine Sekunde. 2 bis 3 Sekunden werden von den meisten Besuchern einer Webseite gerade noch toleriert. Zur Optimierung der Ladezeiten wird in einer Blazor Server-Anwendung der Inhalt der Webseite zunächst als statische HTML-Seite auf dem Server gerendert und dann an den Client (Web-Browser) gesendet. Erst in einem zweitem Schritt wird dann die Seite als interaktive App gerendert. Die Ladezeiten sind aufgrund der geringen Datenmengen wesentlich kürzer als in vergleichbaren WASMs und in der Regel auch kleiner als die von vergleicharen SPAs auf JavaScript Basis.

Ist Blazor nicht viel zu kompliziert?

Neue Technologien weichen vom Bekannten ab und erfordern neue Denkmuster. Softwareentwickler erhalten jedoch oftmals nicht die erforderliche Zeit, um sich mit den neuen Themen vertraut zu machen. Wird dann die neue Technologie von "oben" vorgegeben, die Mehraufwände für eine Einarbeitung aber nicht in den Projektplan einbezogen, führt dies schnell zu Frustration. Man hört dann häufig: "Das taugt nichts." oder "Das ist viel zu kompliziert.".

Sind die Zeit und/oder das Budget begrenzt, setzen Sie in Ihren Projekten auf die Technologie, die von Ihrem Team am besten beherrscht wird. Ist dies HTML und JavaScript, erstellen Sie die Web-Anwendung in HTML und JavaScript. Hat Ihr Team bereits Erfahrungen mit .NET und C#, idealerweise auch mit ASP.NET, steht einer Umsetzung des Projektes mit Blazor dagegen nichts mehr im Weg. Geben Sie Ihrem Team aber auch hier immer genügend Zeit sich einzuarbeiten. "Zu kompliziert" gibt es dann nicht mehr.

Wie sieht es mit der Performance aus?

Nicht nur die Ladezeiten einer Webseite sind relevant. Auch kurze Antwortzeiten bei User-Aktionen sind außerst wichtig. In auf JavaScript basierenden Single Page Anwendungen werden viele User-Aktionen, wie z.B. Mausklicks, direkt im Browser verarbeitet, dies ist besonders performant. Lediglich das Senden und Anfordern von Daten erfordert den Aufbau einer Verbindung zum Server.

Client-Server-Kommunikation

Blazor verwendet zum Verbindungsaufbau zwischen Client und Server zunächst eine HTTP-Verbindung und baut während der Initialisierungsphase eine WebSocket-Verbindung auf oder verwendet, falls dies nicht möglich ist, Long Polling. Aufgrund der permanenten Verbindung zwischen Server und Client entfällt beim Senden oder Empfangen von Daten der Overhead für den Aufbau einer HTTP-Verbindungen. Bei sehr großen Distanzen (z.B. über Kontinente hinweg) können sich jedoch die Latenzen bei der Datenübertragung negativ auf die Performance auswirken. Es sollten daher nach Möglichkeit keine Massen-Events wie Mouse Move oder Scroll-Events direkt an den Server gesendet werden.
Latenzen sind kein Blazor-typisches Problem, sondern dem Netzwerk geschuldet. Sie betreffen jegliche Art der Internet- sowie Intranet-Kommunikation. Optimalerweise stellen Sie daher Ihren Server möglichst nahe an den Besuchern der Webseite auf. Befindet sich Ihre Zielgruppe beispielsweise in Deutschland, sollte Ihr Server in Deutschland oder zumindest in Europa stehen. Ggf. benötigen Sie auch mehrere Server in verschiedenen Regionen.

Der Render-Tree

Blazor verwendet beim Generieren einer Webseite ein virtuelles Document Object Model (DOM), dem sogenannten "Render-Tree". Dieser ist eine Abstraktionsschicht, welche den Inhalt des DOM auf der Client-Seite abbildet. Bei einer Anfrage an den Blazor Server wird während der Ausführung des Programmcodes der Render-Tree zunächst aktualisiert. Dabei werden, soweit möglich, nur Komponenten gerendert, deren Inhalt sich geändert hat. Zur Maximierung der Effizienz wird der Vorher-/Nachherzustand des RenderTree mit einem speziellen Algorithmus verglichen und anschließend nur die tatsächlichen Änderungen an den Browser gesendet. Dort werden dann die modifizierten Elemente im DOM am Stück ersetzt. Auch hierbei erfolgt die gesamte Kommunikation über die bestehende WebSocket-Verbindung.

Sehr empfehlen kann ich Ihnen zu diesem Thema den Artikel Blazor RenderTree Explained von Ed Charbeneau, welcher Ihnen einen tiefen, aber gut verständlichen Einblick in die Funktionsweise des RenderTree bietet. Best Pratices zum Thema Performance-Optimierung finden Sie bei Microsoft Learn.

Ein großer Vorteil der permanenten WebSocket-Verbindung ist die Mögligkeit, Nachrichten direkt vom Server an den Client zu senden. So können beispielsweise in Monitoring-Anwendungen Datenänderungen in Echtzeit direkt an den Client gesendet und dort dargestellt werden; das Client-seitige Pollen entfällt. Das optimierte Rendering in Blazor-Anwendungen sorgt zudem bei Änderungen und User-Aktionen für eine schnelle Aktualisierung der Webseite, welche denen von JavaSript-Anwendungen in nichts nachsteht und diese teilweise sogar übertifft.

Zu Webseiten mit Blazor Server (Teil 2)