How Blazor Performs Against Other Frameworks

We’ll use Blazor Server, Blazor WebAssembly and an ASP.NET Core MVC application to compare performance, looking at network activity to measure against the number of HTTP requests and total load time.

Performance is a key factor when choosing a web application framework. Some key performance factors to look out for include:

• Number of HTTP requests
• Size of each HTTP request
• Total load time

We will look at how Blazor performs as a web application framework. We will use ASP.NET Core MVC, Blazor Server and Blazor WebAssembly and create similar applications in these frameworks to compare the performance.

The Experiment

We have created a sample blog that houses 10,000 articles. Articles are placed into four categories, with each article having one or more categories. Two of those categories are named .NET and SQL Server, and those are what we will be using for our experiment.

To make this as accurate and as fair as possible, each web application will load 10 articles from our .NET category on initialization. Thereafter, we will click on a link that will load up 10 articles from our SQL Server category.

Each application will call the same function and use the same database to retrieve the articles. The function will use Entity Framework Core to return these articles from the database to the application.

Finally, it must be noted that the web applications and the database will sit on localhost.

ASP.NET Core MVC Application

First of all, we are going to run an ASP.NET Core MVC application to see what Blazor is up against. Here is the network activity when the application retrieves articles from the .NET category.

In addition to loading up the HTML document, the application has also loaded the CSS files required to style the application. In terms of load time, it took just under 2.8 seconds to fully load the page.

Now, we are going to load up articles from our SQL Server category and see how it compares.

As you would expect, the load time for the HTML document is significantly quicker. The application has already been initialized, so it’s just the case of retrieving the articles. In addition, the application has loaded the same CSS files, but it has picked up cached copies of the files. Overall, this page has taken just over 150 milliseconds to load—significantly quicker than when the application was initialized.

Blazor Server Application

Now it’s time for Blazor Server to show off its performance. The application does need more HTTP requests compared to the ASP.NET Core MVC application when it is first initialized, as this network activity shows.

There is an increase with eight HTTP requests compared to five in relation to the ASP.NET Core MVC application. Blazor Server needs to establish a websocket connection so the browser and the server can communicate with each other, hence the increase.

In addition, the load time is slightly longer than the ASP.NET Core MVC application. You can see it takes nearly three seconds to load the HTML document. It also takes additional time to load up the websocket connection.

But, with all activity happening on initialization, will it need less work when we click through to the SQL Server category?

Well the answer is yes, as you can see from the network activity below.

For some reason, it’s decided to load a font file, but that’s the only HTTP request it has made. Any data transfer happens through our websocket connection, meaning we do not have to make any additional HTTP requests to update our data. Not only will this have a significant decrease on load time, but also on the amount of bandwidth that is used.

It’s difficult to get an accurate timing as to how long it takes to load the articles. That’s because the network activity shows the websocket providing a constant connection between the browser and server. So to get around this, I used the Stopwatch class in .NET to measure the load time. It took 167 milliseconds to load the articles, which is slightly longer than the ASP.NET Core application.

Blazor WebAssembly Application

Our last experiment is with Blazor WebAssembly. Now, Blazor WebAssembly is different in that we have two applications. One to power the Blazor WebAssembly application, and one to power the API. For the API, we have created an ASP.NET Core MVC API application. The API will be used to retrieve the articles for each category.

Here is the network activity when we first initialize the application.

Now that’s a lot of HTTP requests! Blazor WebAssembly downloads the DLLs into the browser to run the application. It can take over 500 milliseconds to load each DLL. In addition, it can take over two seconds to return a response from the API.

Next, it’s time to load our SQL Server category articles to see if the network activity looks any better.

The only thing that’s changed on the page is the article’s data. As a result, the number of HTTP requests has significantly decreased as you would expect. In addition, the API takes less than 60 milliseconds to get the updated articles, making it quicker than both the ASP.NET Core application and the Blazor Server application.

What We Can Learn from These Results

It does seem that Blazor WebAssembly has a lot of activity when being initialized. There are a larger number of HTTP requests, which adds to the initialization time. However, when you perform a link click, it only needs to call the API to retrieve an updated list of articles, making it the quickest out of all three applications.

Blazor Server needs significantly fewer HTTP requests when being initialized. However, it does take slightly longer compared to Blazor WebAssembly in the sense of retrieving an updated list of articles when performing link clicks.

The ASP.NET Core MVC application has the lowest number of HTTP requests when initialized, but it needs to reload these HTTP requests when performing link clicks. However, it does make use of caching when reloading the HTTP requests that it has previously loaded.

Now this test doesn’t take into consideration how an application would perform if exposed to large volumes of traffic. If you expect your application to get large volumes of traffic, then you might want to go down the ASP.NET Core MVC route. The MVC design pattern has been around a lot longer than Blazor, so you would expect Microsoft to have perfected its performance.

However, that’s not to say that Blazor wouldn’t be able to cope with large volumes of traffic. Blazor does take significantly longer when initialized, but the performance is pretty consistent for all three applications when performing link clicks. Blazor has the benefit of not having to reload the page every time a link click is performed. This will make it seem quicker to the end user.

So, if you wish to show off the capabilities of what a web application can do, Blazor would be a very good choice.