Websites with Blazor Server (part 1)
I’m often asked by customers, project managers and software developers alike why I opted to create my website with Blazor. 6 years since its release, Blazor is still shrouded by questions relating to complexity, performance and scalability. In this blog post, I plan to take a closer look at the most frequently asked questions and share my experiences with you.
At that point in time, Blazor was relatively low on the list. However, I was inspired to take the plunge and try something new by my natural drive to explore new technology and my extremely good experiences with .NET, ASP.NET and the programming language C# to date. I’ve been a big fan of .NET 1.1 ever since it launched in 2003 and my enthusiasm is yet to wane.
Are load times too long for Blazor applications?
Blazor is a framework used to create interactive web applications with C#. Blazor supports both hosting server-side Razor components in ASP.NET Core applications (Blazor Server) as well as the creation of Single Page Apps (SPAs), which can be run in the browser directly (Blazor WebAssembly).
In order to answer the first question, we need to first explore the main differences between Blazor Server and Blazor WebAssembly (WASM). Both Blazor Server and WASM can be used to produce Single Page Applications (SPA). SPAs refer to web applications whereby only individual parts of a page are updated when changes are made instead of requesting the entire page again from the server.
Blazor WebAssemblies use the capabilities of modern browsers to run binary code and consequently render website content independently. However, in order for this to occur, the entire WebAssembly needs to be loaded from the server as IL Code (.Net Intermediate Language) together with the .NET runtime environment and then computed on the client just in time (JiT). It takes just as long for the initial content to be displayed in the browser. WebAssemblies are good for creating configuration tools to be loaded by your website, for example. Users are more likely to accept longer load times if they are already on your website.
Since the launch of .NET version 6.0, Blazor also supports ahead-of-time (AOT) compilation. The WebAssemblies produced are slightly bigger than the corresponding IL files, resulting in longer load times. WebAssemblies compiled AOT offer far better performance in their execution and are also cached in the browser cache. As a result, there are no delays the second time the application is retrieved.
Is Blazor overly complicated?
What about performance?
Client server communication
Blazor initially uses a HTTP connection to establish a connection between the client and server and then builds a WebSocket connection during the initialization phase or uses Long Polling where this is not possible. Due to the permanent connection between the server and client, there is no overhead for establishing the HTTP connection when sending or receiving data. However, when used over long distances (across continents), latencies during data transfers may have a negative impact on performance. For this reason, mass events like mouse moves or scroll events should not be sent to the server directly.
Latencies cannot be attributed to Blazor but the network. They affect all kinds of internet and intranet communications. To achieve the optimum result, it's best to keep your server in a location as close as possible to your website visitors. For instance, if your target audience is located in Germany, you server should be situated in German or Europe at the very least. You may also require several servers in different regions.
Blazor uses a virtual document object model (DOM) when generating a website, otherwise known as a RenderTree. The RenderTree is an abstraction layer that depicts the content from the DOM model on the client side. When a request is sent to the Blazor server, the RenderTree is initially updated when the program code is executed. In the process, only the components with content that has changed will be rendered, where possible. To maximize efficiency, the before and after status of the RenderTree is compared using a special algorithm and only the actual changes are sent to the browser, where the modified elements in the DOM are consecutively replaced. In this scenario, all communications also take place using the established WebSocket connection.
I can highly recommend checking out the article Blazor RenderTree Explained by Ed Charbeneau on this topic for an in-depth yet approachable introduction to how the RenderTree works. Microsoft Learn features [Best Practices]](https://learn.microsoft.com/en-us/aspnet/core/blazor/performance?view=aspnetcore-7.0) on the topic of performance optimization.
One major advantage offered by the permanent WebSocket connection is the ability to send messages directly from the server to the client. In this way, data changes in monitoring applications can be sent to the client in real time and displayed there with no need for client-side polling. Optimized rendering in Blazor applications also enables quicker website updates after changes and user activities, which is in no way inferior to JavaSript applications and in some cases even surpasses them.
Go to Websites with Blazor Server (part 2)