我注意到*.wasm编译的文件大小Rust是可以接受的。然而，一个最小的 HelloWorld 编译AspNet/Blazor将占用将近 2.8MB。
mono.wasm 1.75MB
mscorlib.dll 1.64MB
*.dll ....
如果我理解正确的话，mono.wasm就是在浏览器中运行并运行我们编写的 dll 的 VM。这是否意味着无论我们做什么，我们都不能使文件大小小于 1.75MB？如果没有，有没有办法减少文件大小？
是的，对于“Hello World”应用程序来说，2.8 MB 是相当大的有效负载。但是，Blazor 在很大程度上仍是一项实验性技术，尚未准备好投入生产使用。目前生成的输出如此之大的原因有很多：
您当前的应用程序在解释模式下运行，其中mono.wasm文件将 CLR 发送到浏览器，允许它执行您的 DLL。如本文所述，使用 Ahead of Time Compilation (AOT) 是一种更快、更有效的方法。这将允许编译器去除任何未使用的库函数，从而提供高度优化的输出。
WebAssembly 运行时本身的功能非常有限，未来版本将添加垃圾收集和 Blazor 可以直接使用的各种其他功能。目前mono.wasm包括它自己的垃圾收集器。
Blazor 项目本身有许多未解决的问题，描述了正在积极进行的各种优化。它已经执行了 tree-shaking 和其他各种优化，但是这种类型的工作需要时间。
目前（2021 年），一个 hello world Blazor WASM 应用程序（Visual Studio 项目模板）下载了超过 17 MB 的数据。当使用 gzip 时，它减少到 7 MB - 如果我们考虑到还没有包含应用程序代码/逻辑的事实，这真的是巨大的！
但我发现在调试过程中链接器似乎没有激活。如果我们以发布模式（-c Release开关）发布应用程序，则只加载必要的文件。这会将传输大小增加到 5.6 MB，甚至在激活 gzip 的情况下为 2.4 MB。您还可以在已发布文件夹的大小中看到这一点：
$ dotnet publish --output publish_debug -c Debug
$ dotnet publish --output publish_release -c Release
$ du -hs publish_debug/
30M publish_debug/
$ du -hs publish_release/
11M publish_release/
它仍然是可观的数据量。但是，由于调试模式下显示的 17/7 MB 大得多，此信息可能有助于其他人找到此问题。
由于问题来自 2018 年，因此可能还有兴趣提及框架缓存在3.2.0-preview2. 这意味着：运行时和框架在最初从服务器获取它们之后存储在浏览器缓存中。由于这是由 JavaScript 处理的，因此在这些文件被缓存后不会再向它们发出请求！服务器可能会以 304 Not Modified 响应，但这仍然是一些我们现在没有的开销。
这也意味着它们只出现在网络选项卡中的第一页加载中！如果要测量没有缓存的加载时间，请删除这些域的缓存。这必须手动完成！在浏览器控制台中选中no cache复选框是不够的，因为 Blazor 似乎将本地存储与 JS 一起使用。