Websites with Blazor Server (part 1)

Why Blazor?

Back when I founded scotec Software Solutions AB in fall 2022, I needed to decide which technology to use to create my website. At first, the obvious choice was to go with a content management system like WordPress or Typo3. These systems produce great results with relatively minimal work. Creating the website with HTML and JavaScript was another viable alternative. There are no lack of frameworks and libraries available to help with this. Using these resources, it's possible to have a website up and running pretty quickly.

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.

In the first part of this post, I want to address questions on load times, the complexity of Blazor applications and performance. In the second part, I will then answer questions on resource consumption, scalability and using JavaScript in Blazor applications.

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.

The success of a website is contingent on user acceptance. Accordingly, public company websites and in-house applications are designed with the shortest possible load times. Ideally, they should take less than a second to load. The majority of users are not willing to wait up to 2 to 3 seconds to visit a website. In order to optimize load times, website content is initially rendered as a static HTML page on the server and subsequently sent to the client (web browser) in a Blazor Server application. The page is only rendered as an interactive app in the second stage. Due to the low data volumes, load time are significantly shorter than withs comparable WASMs and generally also shorter than the load times for comparable SPAs that run on JavaScript.

Is Blazor overly complicated?

By definition, new technologies tend to vary from the ones we know and love, requiring an entirely new approach. However, software developers are rarely given the time required to familiarize themselves with new topics. The technology is generally introduced by their superiors with no consideration given to the time required to become acquainted with it in the project schedule, something that quickly leads to frustration. It’s therefore no surprise that phrases like ‘the software doesn’t work’ or ‘it's far too complicated’ are commonplace. If there are time and/or budget constraints, you generally want to rely on the technology your team is most familiar with for your projects. If this happens to be HTML and JavaScript, you can create your web applications in HTML and JavaScript. If you team has prior experience working with .NET and C#, ideally also ASP.NET, there’s nothing stopping you from executing your project with Blazor. Although do make sure to give your team enough time to get to know the framework. ‘It’s too complicated’ won’t be an excuse any more.

What about performance?

Website load times aren’t the only factor to take into consideration. Quick responses to user activities are also extremely important. In JavaScript based single page applications, many user activities such as mouse clicks are processed in the browser directly, which offers particularly high performance. A connection to the server is therefore only required to send and request data.

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.

RenderTree

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)