Blazor Download Progress Should Take Into Account Bundle Size And Expose Real Download Information

[elepner]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I was very excited to see that with .NET 7 Blazor team has introduced download progress. Bundle size is known limitation of Blazor client, nice and informative progress bar is essential for any serious web app to mitigate this problem. To achieve this essential goal our team has to use custom loader. DIY solutions in such sensitive area are quite dangerous - each error or bug in this area means potentially lost customer. Therefore we were about to drop our custom loader with new .NET but soon realised that blazor progress shows completely bogus data. I don't know how Blazor computes total progress but here's what we encountered with: Total AOT bundle size is 137 Mb (which is much, but we can put up with) dotnet.wasm occupying the largest part of that: So, real download progress is 19%, whereas here's what Blazor shows:

It got stuck at 98% for the rest of 100Mb of download. Such user experience is even worse than indefinite spinner because it misleading that application is frozen and nothing happens at all. At current state I find this feature useless or even harmful.

Describe the solution you'd like

Bundle download state should be explicitly exposed. Developers should have access via JS to bundle size, total progress, eventually to a flag that progress is not responding. Ideally all pieces of information related to bundle should be available to developers for providing the best user experience:

• Total bundle size
• Current progress
• Individual item size
• Individual item progress
• Download speed
• Estimated time

Additional context

No response

[javiercn]

@elepner thanks for contacting us.

Our bundle works on the number of files, we do not know the size of the app at the time we are loading it.

It is generally ok to use the number of files to track the download progress since there aren't usually big outliers (like a 100mb wasm file) that skew the result and loading usually happens relatively quickly for an individual file.

In cases like yours we think it is best if you provide your own (more sophisticated approach) as you seem to be currently doing. The loader that we have in place is just a default experience that we expect developers to tweak to adapt it to more complex scenarios if needed.

[elepner]

I have created default counter/Weather forecast application from VS 2022/.NET 7. Then published this project with AOT. Total gz bundle size is 5.61MB where dotnet.wasm.gz takes 3.27 (58% of total bundle size).

I served it using http-server with -b flag. Than I tried to boot application with network throttling of slow 3G. It took 2.5min for application to boot which is OK, but it stuck on 96% for 50 sec. How likely do you think user would think that something went wrong and hit refresh button forcing themself to download dotnet.wasm file again? After refresh the user would stuck on 96% for 50 sec again without any chance to understand that everything is OK and they need to wait a little longer.

How has such behavior even passed quality control? The feature in such shape should not get into release, IMO.

Vast majority of Servers/CDNs provide Content-Length header, so you do have information. Yes, we can implement it by our own, but big bundle size is know issue of Blazor and proper progress reporting can mitigate this problem. This is something that each application which uses Blazor has to deal with.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.