Blazor Download Progress Should Take Into Account Bundle Size And Expose Real Download Information
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 281
Description
### 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_
Contributor guide
Research direction
Start by tracing the existing Blazor download-progress implementation described in the issue, comparing its reported progress with the full AOT bundle download. Done would require an agreed design for exposing accurate bundle and item metrics, including total size, current progress, speed, and estimated time, followed by validation against the reported 98% stall.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 22/100