我注意到*.wasm编译的Rust的文件大小是可以接受的。但是，由AspNet/Blazor编译的最小HelloWorld占用将近2.8MB。
mono.wasm 1.75MB
mscorlib.dll 1.64MB
*.dll ....
如果我理解正确，那么mono.wasm是在浏览器中运行并运行我们编写的dll的VM。这是否意味着无论我们做什么，我们都不能使文件大小小于1.75MB？如果没有，是否有减小文件大小的方法？
答案 0 :(得分：3)
是的，对于“ Hello World”应用程序来说，2.8 MB是相当大的负载。但是，Blazor仍然是一项非常实验性的技术，尚未准备好用于生产。当前产生的输出如此之大的原因有很多：
您当前的应用程序以解释模式运行，其中mono.wasm文件将CLR附带到您的浏览器，允许它执行DLL。一种更快，更高效的方法是使用时间提前编译（AOT）as described in this article。这将使编译器可以剔除所有未使用的库函数，从而提供高度优化的输出。
WebAssembly运行时本身的功能非常有限，将来的版本将添加garbage collection以及Blazor将能够直接使用的各种其他功能。目前mono.wasm包括自己的垃圾收集器。
Blazor项目本身有一个number of open issues，描述了正在积极进行的各种优化。它已经进行了摇树和其他各种优化，但是这种类型的工作需要时间。
答案 1 :(得分：1)
目前（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 年的，所以可能也有兴趣提及 framework caching was improved in 3.2.0-preview2。这意味着：运行时和框架最初从服务器获取后存储在浏览器缓存中。由于这是由 JavaScript 处理的，因此在缓存文件后不会再向这些文件发出请求！服务器可能会以 304 Not Modified 响应，但这仍然是一些我们现在没有的开销。
这也意味着它们仅出现在网络标签的第一页加载中！如果您想在没有缓存的情况下测量加载时间，请删除这些域的缓存。这必须手动完成！选中浏览器控制台中的无缓存复选框还不够，因为 Blazor 似乎将本地存储与 JS 一起使用。