Blazor performance

I would like to start using Blazor, despite the fact that it is still at the alpha level.

As I understand it, Blazor uses WebAssembly to compile C# on the client side.

And I have these questions:

Does this approach run faster than, for example, React / Vue.js, compiled in JavaScript?

Is it true that the browser will need to download the WebAssembly library every time the page loads?

On the Internet there aren't any comparisons of the performance of popular JavaScript frameworks. So I would like to know the theoretical performance of the new framework from Microsoft.

Solution 1:

Is it true that the browser will need to download the WebAssembly library every time the page loads?

No, browsers can cache the files. Common CDNs for Blazor applications will do the trick.

Is this system faster to work than, for example, React / Vue.js, compiled in JavaScript?

Blazor uses WebAssembly, On paper WebAssembly should be faster than any JavaScript library. However, not all browsers have a mature WebAssembly parser yet. So you might find that browsers will not run WebAssembly in an optimal speed as of now.

You can create a small Blazor application and run it in Firefox, Chrome or Edge. In most cases, Firefox runs Blazor applications much faster than Chrome or Edge, which implies that browser makers still need to improve, and even Firefox can improve.

If your application needs to access the DOM frequently, then definitely WebAssembly / Blazor will be slower compared to any JavaScript libraries since WebAssembly can’t directly access the DOM without using Invokes (which is slow at the moment. Please refer my Blazor benchmark below).

On Firefox, 10,000 RegisteredFunction.InvokeUnmarshalle calls to empty methods takes 250 ms while Chrome and Edge need more than 2400 ms in my PC. In pure JavaScript it takes below 10 milliseconds for the same scenario.

Additionally, the current implementation of Blazor has its own MSIL engine on top of the browser's WebAssembly engine, which means there are two interpreters working to run a Blazor project, like two translators interpreting a conversation instead on one. Currently Microsoft is working on an AOT compiler, which is not yet released. Once it's released, Blazor will be much faster than the current implementation.

Mono and WebAssembly - Updates on Static Compilation

We can safely assume that the web assembly is the future of web development, but at the moment we can’t say anything about Blazor’s future. On paper, Blazor can be faster than any framework out there, however we need commitment from WebAssembly maintainers, browser developers, Microsoft and the communities to make the theories practical.

Update 10th July 2018

There are new proposals in the WebAssembly repositories.

1. Allowing WebAssembly to handle DOM directly. Interface types #8

2. Reference Types for WebAssembly with GC. Reference Types for WebAssembly

The above two proposals will pave the path to much faster interaction between the DOM and WebAssembly in the future. In other words, Blazor will be much faster in the future.

Update 17 October 2018

The Firefox team was able to reach a JavaScript-to-WebAssembly call as fast as JavaScript-to-JavaScript method calls. As of now Firefox is far ahead of any other browsers when it comes to WebAssembly support.

Calls between JavaScript and WebAssembly are finally fast

Solution 2:

On April 2021 we did a trial of Blazor WASM against a legacy Angular.js web app, as well as against Flutter Web (HTML & CanvasKit renderers). We've recreated the main page of the legacy app (which is essentially a big data grid with filters, pagination, sorting etc.). Here're a few takeaways:

                                                                      Lighthouse perf. Scores
                   Grid Displ.  Data transf.  Data uncomp.  Reqs.  FCP   SI   LCP  TTI  TBT  CLS
Blazor*            2.2s         4.7MB         13.7MB        99     0.5s  1.6s 0.5s 2.1s 1.3s 0.01 
Flutter HTML       1.7s         2.1MB          3.7MB        15     1.9s  2.5s 2.2s 2.3  0.2s 0
Flutter CanvasKit^ 2.8s         4.7MB         10.5MB        17     1.0s  2.2s -/-  2.2s 1s   0   
AngularJS`         1.9s         2.0MB          5.7MB        294    2.1s  2.2s 2.6s 2.6s 0.1s 0

• Grid Displ. - time it took to completely display the gird (judging by the timeline and screenshots gathered by Lighthouse)
• Data transf. - data transfered when loading the app (Network tab in DevTools, caches cleared)
• Data uncomp. - uncompressed size of data transfered (Network tab)
• Reqs. - number of requests issued while loading the app (Network tab, caches cleared)
• Lighthouse Performance score breakdown
• Tested on Windows 10, Google Chrome Version 89.0.4389.128 (Official Build, 64-bit), Intel Core i5 4460, 16GB RAM, wired LAN connection
• Relase configs used to build apps, Blazor WASM/.NET 5, Flutter (Channel beta, 2.1.0-12.2.pre), AngularJS 1.7.7

*Lighthouse gives incorrect LCP value (it counts Blazor's blank 'Loading...' page as LCP)

^Flutter's CanvasKit renderer doesn't allow Lighthouse to get LCP measurement

`Legacy app is much bigger then PoCs created, there're many more screens and assets which affect the number of requests upon app launch