Delays and overall performance are directly related to the execution mode of a Blazor WebAssembly application. In Debug mode, any change to component properties or bound parameters could cause the UI to freeze for 20–30 seconds or even longer, depending on the complexity of the page.
How is the problem reproduced?
If the application is started through Visual Studio (dotnet build / dotnet run), long delays can be reproduced consistently. However, after publishing the application, the situation changes dramatically:- dotnet publish is executed;
- the application is launched from the command line;
- the delays almost completely disappear.
This is an important point when diagnosing performance issues in Blazor WebAssembly applications.
Why does this happen?
Debug mode runs significantly slower when using dotnet build / dotnet run:- C# is compiled into IL (Intermediate Language);
- the browser downloads the IL assemblies;
- the code is executed through the .NET runtime running in WebAssembly.
In the Debug configuration, many optimizations are disabled, so heavy computations execute much more slowly. This is especially noticeable when using the SixLabors.ImageSharp library, which heavily relies on image processing and transformations.
What does dotnet publish change?
Publishing enables Release optimizations:- unused code is removed (trimming);
- application size is reduced;
- runtime optimizations are enabled;
- execution overhead is reduced.
Even this alone can improve performance several times over. Important!
AOT is not enabled automatically! There is a common misconception that dotnet publish automatically enables AOT compilation. In reality, full Native AOT must be enabled explicitly using a special project setting:
<RunAOTCompilation>true</RunAOTCompilation>
Only after enabling this option is the IL code compiled into native WebAssembly that the browser can execute directly. Conclusion
The difference between Debug and Publish modes in Blazor WebAssembly can be enormous. Before analyzing performance issues, it is important to verify:- whether a Release build is being used;
- whether AOT is enabled;
- whether the issue still reproduces after dotnet publish.
In many cases, the published version of the application runs several times faster and completely eliminates critical UI delays that occur while debugging the application.