Continue reducing the size of Blazor WebAssembly apps

[danroth27]

We should continue to look at reducing the download size of Blazor WebAssembly apps to remove any remaining dead weight code.

Related runtime issues:

• MonoVM runtime size-reduction for WebAssembly runtime#43778
• Core Managed libraries size-reduction for WebAssembly runtime#44530 (see the "Future release" list)
• Make Blazor WebAssembly apps fully trimmable #49409

On the Blazor side, we could look at enabling more of System.Text.Json by using a source generator.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[TanayParikh]

Related to #42284 ?

[danmoseley]

cc @eerhardt fyi

[StephenEhlers]

@danroth27 @mkArtakMSFT Is there a sample client webassembly project that has all the best settings for getting the project down to the 1.5mb size or maybe less now in .net 7.0? I have applied all the trim settings I can find and removed everything except for the most basic components to load blazor up but I am still riding at 3.1mb.

I got the 1.1mb number from this video:

https://www.youtube.com/watch?v=Jte_VwsSazs

Thanks for the help!

EDIT:

I ended up finding my issue, I had everything set up in my csproj just fine, it was that my local IIS instance did not have compression enabled properly and the web.config generated by the publish process was also missing details. Once I got this updated I got down to sub 2mb data transfer since it was able to take advantage of the brotli compressed files generated in the publish process.

[eerhardt]

@StephenEhlers - have you also installed the .NET WebAssembly build tools?

If you install that, the dotnet.wasm file gets even smaller after publish, because it is "re-linked" with only the code your app needs.

[danroth27]

@StephenEhlers Take a look at https://github.com/danroth27/SatelliteSimulator, which should be ~1MB when published.

The key things to get a minimal Blazor WebAssembly app size:

• Install the .NET WebAssembly build tools: dotnet workload install wasm-tools or install the VS optional component as shown in @eerhardt 's comment. This will enable runtime relinking
• Enable invariant globalization if that's sufficient for your needs: <InvariantGlobalization>true</InvariantGlobalization>
• Disable time zone support if you're not using it: <BlazorEnableTimeZoneSupport>false</BlazorEnableTimeZoneSupport>
• Publish the app with a release build (dotnet publish -c Release)
• Make sure you're using a host for your app that correctly serves the precompressed files form the published output. If the Blazor WebAssembly app is ASP.NET Core hosted we handle this for you. Azure Static Web Apps deals with this as well. GitHub Pages does not.
• Look at the app "transferred" size, which is the compressed size.

For additional details see https://learn.microsoft.com/aspnet/core/blazor/host-and-deploy/webassembly.

[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.

[mkArtakMSFT]

Closing as the remaining work is already tracked with issues in the runtime repo. That said, this is an effort we're not going to stop and will be looking for new ways to reduce the size as we move forward.