Optimizing a Blazor WebAssembly application size

The size of a Blazor WebAssembly application is important to reduce the loading time. Indeed, like any website, the page including all resources must be loaded before the user can use your application. If there are fewer things to download, it should load faster. It also reduces the data transfer on the server, so it reduces the hosting costs.

#Removing unused code using the Linker

The .NET framework contains lots of types and methods. This is great when developing. However, this means that DLL are bigger which is not great as there are larger to download. Linking a Blazor WebAssembly application reduces the application's size by removing unused code in the application's binaries.

By default, the linker is enabled when building in Release configuration:

dotnet publish --configuration Release

The following chart shows the size of the _framework folder of a Blazor WebAssembly application for each compression algorithm with the linker enabled or not. These values may differ for your application as it depends on which features it uses. So, this is just an indication to show how useful the linker is:

#Pre-compressing static files

A Blazor WebAssembly application consists of many DLL, JS, JSON, and binary files. By compressing these files using Brotli or gzip, you can reduce the size of the application by about 60%. Instead of compressing them on-demand, you can compress them once during the compilation with the maximum compression options. It requires more time but it is done during the compilation, so this is not a big deal. The following chart shows the size of the _framework folder of the default Blazor template for each compression algorithm:

By default, the Blazor tooling compress files during compilation in Release configuration:

dotnet publish --configuration Release

You can see that the output contains 3 versions of each file:

Then, you can check in your browser that the files are served using Brotli or gzip:

#Removing time zone support

Blazor WebAssembly supports timezones by adding a data file with the information of all time zone. So, when you need to convert time between time zone it first read this file to get the info, then it can compute the right time. You can check the size of this file in _framework/wasm/dotnet.timezones.dat

If the app doesn't require this feature, you can disable it by setting the BlazorEnableTimeZoneSupport property in the application's project file to false:

<PropertyGroup>
  <BlazorEnableTimeZoneSupport>false</BlazorEnableTimeZoneSupport>
</PropertyGroup>

After setting this property to false, the files won't be generated in the output folder when publishing the application, so you can save a few kB.

#Removing collation data

Collation information is included to make APIs such as StringComparison.InvariantCultureIgnoreCase work correctly. If you're certain that the app doesn't require the collation data, you can disable it by setting the BlazorWebAssemblyPreserveCollationData property in the application's project file to false:

<PropertyGroup>
  <BlazorWebAssemblyPreserveCollationData>false</BlazorWebAssemblyPreserveCollationData>
</PropertyGroup>

This property configures the linker to remove some data. The result is a lighter mscorlib.dll. In the default application, the Brotli file is 115kB lighter.

#Additional resources

• ASP.NET Core Blazor performance best practices

Do you have a question or a suggestion about this post? Contact me!