Blazor wasm size and load time is the worst and biggest problem ever and should be the #1 priority

[awillSoftwares]

Blazor size and load time drawback is quoted in any article/discussion talking about blazor.
Blazor size and load time is prohibitive.
This make blazor unusable in the most common web scenarios.
If you want to see Blazor large adoption, the only way is to reduce the Blazor size.
I'm migrating back to Svelte because it makes Blazor unusable for my use case.

I like to use Blazor in all my applications. The bundle size does not allow me to do that;

Prerendering is not a solution because while Blazor is loaded, the entire application is unresponsible.

I create a system using Blazor and the load on mobile network makes my app take more than 15 seconds to load.

Today, more than 60% of all sites access is in mobile devices / mobile networks.
Not all users have high speed connections in all places. Every bite counts.

Even with trimming and serving files with Brotli, My app ends up with 1.8 MB event with

BlazorEnableTimeZoneSupport = false
BlazorEnableCompression = true
BlazorWebAssemblyPreserveCollationData = false
InvariantGlobalization = true

This talk express exactly the wrost problem with blazor: https://news.ycombinator.com/item?id=21093669

In ANY discussion about blazor, the size of bundle appears.

[ShreyasJejurkar]

Hi there, have you tried trimming the blazor WASM app using provided trimmer options!?
Check this doc for more help -> https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/configure-trimmer?view=aspnetcore-6.0

[awillSoftwares]

Yes, i'm using trimming and serving the .br files with Brotli compression. The bundle size still tremendous and the load time is terrible. I set using:

<PublishTrimmed>true</PublishTrimmed>
<TrimMode>link</TrimMode>

[javiercn]

@awillSoftwares thanks for contacting us.

We continue to work on making improvements to reduce the size of the Blazor Wasm runtime and libraries.

Unfortunately, there is no magic bullet that allows us to make the size go down. Ultimately as the conversation you point out, there is a .NET runtime that needs to be downloaded.

That said, in most applications this is no different than the vendor bundle of third-party dependencies that many apps end up including. If you need ultra-fast and minimal downloaded code and Svelte or other framework gives you that it's great. Blazor Web assembly is not yet the right choice in those cases and that is ok.

If you want to keep using .NET and C# to author your web UIs but you need fast startup times, you can consider using Blazor Server to handle the initial page load on first visits and use separate logic to download the Blazor Webassembly bits in the background so that on subsequent visits you can start with the webassembly runtime already downloaded.

[danroth27]

I create a system using Blazor and the load on mobile network makes my app take more than 15 seconds to load.

Is this problem mostly an issue on mobile? When you visit the same site from desktop browsers do you see anything close to this load time? We've heard complaints about Blazor WebAssembly load time on mobile from a number of users, which makes me think we may need to do some mobile specific investigations.

[veikkoeeva]

Judging from the size it could be worse too. Mobile networks can easily be congested and/or used from moving systems (bus, train, tram etc.) and so small size and not many files to download is quite important. Factor is also mobile networks and the costs of using them globally.

I think other issue after this is if Blazor still builds a separate DOM is that likely will take (too) much resources on commonly used (low end) mobile phones. As in React is not used either. Maybe one benchmark is something like https://lit.dev/ here.

With a grain of salt, I/we haven't used Blazor for a while and last time was before AOT on line of business type of thing on factory floor so this is more like general observations from other use cases with other tools.

Edit: Firstly, I don't want to complain but give a bit of reasong that goes in our company and that of my colleagues in others. :)

I add to @awillSoftwares' notes that there's already 6G networks here and majority is in 5G but in projects likely Blazor is still likely deemed too heavy in use cases that involve people in public space. Such as stadiums, train, bus other stations or moving objects (hopping between stations, other issues with fast moving objects) simply because even beefiest networks get congested. Native apps is an option around some issues, but not when downloads are expected in congested areas. Then submissions to app stores and the risks involved there may not be worth the trouble.

The other thing is rendering, indeed, Svelte, Lit hyperHTML (FAST where applicable?) work with template string literals (cached) reacting to changes. Then there is the move towards web components/custom elements based systems in general.

It appears that customers with tolerance to heavier loads as in with industrial systems (e.g. factory floor, fairly closed) and line of business ask for longevity: web components/custom elements (and reuse), maybe not a CSS frameworks but "normal CSS with grids and stuff" and no complicated build systems (e.g. "simple Rollup script" or Esbuild should do + Parcel CSS). Rightly or wrongly, more often these days customers feel tired of elaboreated JS/TS setups that break if not constantly maintained.

Speaking for myself, I would be happy if it were possible to easy compile .NET (C#/F#) to WASM modules and use them as-is, say, with Lit doing the rendering and calling into WASM. Maybe in some projects could take the heavier payload if there is a roadmap to refer to.

[awillSoftwares]

@danroth27
I'm testing in slow 3G, fast 3G and 4G network to see the worst case scenario, the not too worst and the worst as little.
Even in fast network accessing a server in another country.
Here in Brazil most of people connect in mobile on 3G networks, and unstable mobile networks, so, its important to test how the things will work because with mobile networks we can't trust too much, every byte counts.

I rewrite the same exactly application in Svelte and the compiled build package down to 9KB.

as @veikkoeeva said, the way Blazor render and apply updates is slow and have problems if we change the DOM with external javascript libraries. Svelte doesn't use a virtual DOM representation. Instead, it parses and analyzes our code, creates a dependency tree, and then generates the required JavaScript to update only the parts of the DOM that need to be updated. This approach generates optimal JavaScript code with minimal overhead, providing really fast updates, and use less resources.

Svelte play very well with javascript libraries, even if they change the DOM. Works well in any resource-less machine.
On the other side, Blazor is bloated and not efficient at render updates.

I suggest that Blazor do the things more like Svelte, generating a javascript to update the dom without virtual DOM, it will make integration with 3th party JS libraries that change the DOM, possible.

I like Blazor code way more than Svelte, I want to use Blazor even in my blogs, hello word and everywhere but the size is prohibitive even for corporative solutions.

I think the size must be priority and DOM changes must be done with generated javascript like Svelte does, not like Blazor does, this needs to be rethought completely.

But in Svelte, things just works. I can change the DOM with almost every javascript library and when i update some state, automagically and surgical things are changed in DOM.
As was I said, In ANY discussion about blazor, the size of bundle appears. Do some google research. This make Blazor unusable for most (every) case scenarios.

It's a shame because I would love to use Blazor. I try everything, but no way.

PS: I have successfully implemented Blazor server-side rendering using authentication. Where i can publish and share the code?
Thank you, very much.

[manishbisen]

Is this size issue still persist ?
I am planing to develop app with Blazor.
If this issue still persist then I can wait for some days until it come to stable state.
Someone please confirm.

[javiercn]

@awillSoftwares thanks for the additional input.

Unfortunately, we won't be changing the Blazor rendering model any time soon. It would be a huge breaking change and ecosystem reset for everybody and that is not something we are willing to do.

It seems that in your case, Svelte might be a better fit, and that is ok. We try to enable as many customer scenarios as we can, but we still have work to do.

As much as we can reduce the size, there is going to be a WASM .NET runtime and BCL that needs to be downloaded and that's not something we will be able to avoid. We continue to invest in ways to shrink it as much as possible, but it will never be able to compete with a framework that doesn't involve a runtime.

As for comments about rendering speed, etc. I would be cautious here with just saying "rendering is slow" as it is a subjective statement that doesn't provide any concrete details.

• What is considered to be slow?
• Slow rendering what?
• On what hardware?
• Does it matter for your app?

Performance is not something that exists in the vacuum, it is defined within a context that includes the source code of your app, your environment and the inputs you expect. If you don't include those, you can't claim that something is fast or slow or that it matters at all. You might be extracting the last bit of performance in the hardware, that it might not matter to your app or your customers.

For the vast majority of apps and use cases the rendering model for React is perfectly fine, and I'm sure there are faster alternatives in certain circumstances, but the reality is that it very likely doesn't matter for your app.

To summarize my comment here, there is always going to be a cost to pay for the runtime download, as much as we try to shrink it. And as for rendering performance, we don't think this is an issue in the vast majority of cases and not something we plan to redesign.

Finally, I want to reiterate that if Blazor doesn't serve your needs and you are happy using any other SPA framework out there, we offer great support for integrating any SPA frontend with an ASP.NET Core backend :).

[javiercn]

@manishbisen Not sure what your requirements and environment are, so its impossible to answer your question. For the majority of cases, you should be fine.

[javiercn]

@veikkoeeva thanks for the feedback.

We understand that mobile networks can be more challenging specially when dealing with things like congestion. I think though that that is something better addressed by supporting HTTP/3 in your backend to deliver content (experimental support is already there in .NET 6.0 and I believe its on the roadmap for .NET 7.0)

Edge, Chrome, Firefox already support it (for a while) by default and Safari does too under a flag, sooner rather than later it will do so too.

It's obvious that the smaller the download the less problems you are likely to encounter, however it is a trade-off between productivity, complexity, maintainability and performance. If you are not willing to pay the download cost or the framework performance is not enough to meet your goals, then using any other framework is perfectly valid.

Finally, I would point out that it is not an all or nothing situation. You can have some code to deal with the most performance critical parts (download wise) of your app and implement the rest of your app using Blazor Webassembly. You can integrate Blazor Webassembly with other frameworks via custom elements or concrete integrations with your framework.

[veikkoeeva]

@javiercn Thanks. I think I need to look into https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-net-6-rc-1/#blazor-custom-elements. I hope not coming across the wrong way, more like a bit muddled way of writing what factors in also in the intended use. Heavier indeed works in certain environments, such as factory floor, line of business, some others.

I'd like to be able to use Blazor more, so it happened to come across this and now stress a bit different factor that I think the main issue in this space is that clients are asking if they can with Blazor reuse custom elements developed elsewhere (e.g. developed by those many systems that use Lit, though the result is browser standard component that's easy to use), use "plain CSS" and so on. The aim is clearly longevity in the stack and tooling to keep it going. I know I'm biased here. I don't know what stops other than developer perception one can't or how to exactly counter the argument that is that "we need to download also all the Blazor bits even if we only want business logic WASM".

I think if there is enough logic, then compiling to WASM and downloading libraries/framework makes sense. In any case there will be more code and libraries can be loaded in parallel and cached where applicable. Then combine that with custom elements from elsewhere that call into the WASM compiled code.

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

[hoangdovan]

@awillSoftwares Same situation here. We also need to comeback to Angular after some investment in Blazor. Blazor is not suitable for public face website now. I don't think MS can change this situation soon. Do not use Blazor if you have strictly requirement for speed and download size. Even MS does not use Blazor in their website, so why should we? I can see only use case for Blazor with internal web app which bundle size is not problem.