Critical perfomance issue Blazor webapp interactive auto #8834

maria_ruiz created 26 days ago

ABP Framework version: v9.0.4
UI Type: Blazor webapp Interactive Auto
Database System: EF Core (SQL Server)
Tiered (for MVC) or Auth Server Separated (for Angular): no

Good morning,

In relation to this ticket:
https://abp.io/support/questions/8743/Critical-Performance-Issue-in-Blazor-WebAssembly-with-ABP-Affecting-Multiple-Production-Applications

The conclusion you gave us was to migrate to webapp, this migration has been done at a great cost of time,
However the problem is still there, the wasm is downloaded using blazor server and it is still very slow.

We have now changed it to use a CDN to download the files,
We have published it and we can give you the link to the application where it has been applied,

Any other solution?

enisn created 25 days ago

Support Team .NET Developer

Hi,

Sorry to hear that scenario that you are experiencing. Unfortunately, the current performance issues are inherent to Blazor itself. As it operates as a WebAssembly, initialization occurs within the browser and is highly dependent on client-side performance. Consequently, slower machines or mobile devices may require significantly more time to initialize the application.

I worked on this performance situation formerly and here is my findings:
Blazor performance is related to the following 2 points:

Network Quality (How fast the connection)
Client-Performance (Initializing WASM runtime on the client-side)

And 2 main point can affect to the performance:

If both are the problem, you can't even see the page properly, it takes over than 10secs

As far as I understood, you already made all the optimizations about networking including using CDN. But the main topic is the client-performance currently.

This was my benchmark results back in ABP v7.4 and .NET 8 RC.1

Here how it works:

Download the wasm & javascript
Starts dotnet javascript
Javascript calls dotnet.wasm and starts initialize dotnet wasm runtime.
- After dotnet wasm runtime initialized:
It downloads entry point and all the dependent DLL files.
Loads all the DLL files to the runtime.
Then your application starts working.

So your code won't be compiled to the WASM. Only dotnet runtime is WASM in the scenario, and initializing that dotnet runtime written in wasm takes some time. And than second bottleneck is loading DLL files to the runtime. If you have a lot of DLL files, it'll take a lot more time even they're already downloaded. With ABP, there are already a lot of DLL files for infrastructure and modules.

What can you do next?

You can't make any changes for dotnet runtime and its initialization in the current state but you can try assembly trimming to reduce your publish file counts or their sizes: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/configure-trimmer?view=aspnetcore-9.0
Even you can't reduce your publish output, you can hardly cache them by using PWA configuration: https://abp.io/docs/latest/framework/ui/blazor/pwa-configuration
The first openning will be still slow but second visit will be a lot more fast in release configuration.(Check the release service-worker implementation in that document.)