.Net Blazor WebAssembly听起来真的很棒。它可以完全在客户端运行，这意味着不需要动态服务器，甚至可以将其托管在CDN上。更好的是，它可以将其转换为可安装的PWA。所以我看了一些演示，并震惊地发现，在synfusion.com上加载示例页面大约需要15秒，并且具有良好的互联网连接。
以下是示例：https://blazor.syncfusion.com/showcase/wasm/health-tracker/
我完全理解，需要下载整个.Net Webassembly，这自然需要一些时间，我已经测量过，当页面的运行时已经缓存时，后续加载的时间“只有”大约3到5秒。
然而，这仍然是很多，在我看来不能在真实的生活secnario。哪个用户会等待一个网站，需要15秒钟加载？
所以我的问题是，肯定有一个内置的方法来改善启动时间.也许一个人可以只加载部分.Net插件，这是必要的主页，或任何页面的用户请求，工作.我理解thoguh，这可能是困难的，因为.Net插件很可能是非常互连，大多数部分将依赖于其他部分。我可以想象有一个传统的Html/Js/CSS页面服务第一，直到Webassembly运行时下载。也许一个人可以至少显示尚未交互的UI，给给予用户一种速度感？还有，为什么后续的加载需要3秒以上的时间？运行时应该被缓存，从该高速缓存中检索它真的需要那么长时间吗？
如果有人知道如何改善.Net Blazor WASM应用程序的启动时间，我很高兴听到一个解决方案，因为默认的启动时间长得令人无法忍受，至少对我来说不适用于任何真实的世界场景，这真的是一个巨大的耻辱。
PS：
当然，我也尝试构建自己的页面，并测量了初始启动时间和缓存时间，这两个都比syncfusion快，但当然，在编译和构建时，应用程序的大小也要小得多。
啊，是的，对于任何人要求一个最小的可复制的例子，采取在Visual Studio中的Web App模板，配置为交互式渲染模式= WebAssembly，并勾选“包括示例页面”。
2条答案
按热度按时间r6vfmomb1#
我想明白了：.Net 8通过引入一个名为
Auto的新渲染模式解决了这个问题。仅仅添加@rendermode Auto指令就大大缩短了启动时间。这实质上意味着，在初始页面加载时使用@rendermode InteractiveServer，在每个后续加载时都使用@rendermode InteractiveClient。在初始加载时，服务器服务请求，所需的wasm在后台下载，并且在每个forthoughfollowing请求上使用缓存的webassembly，因此甚至不建立与服务器的连接。这提供了两个世界的最佳情况，唯一的缺点是，需要两个项目-服务器上的一个和客户端上的一个。ezykj2lf2#
这里有一些技巧，你可以使用，使事情变得更好。
1.在索引页面上放置大量的静态内容来分散用户的注意力（如果有服务器，则进行预渲染）
1.请确保您没有启用AOT编译-它会增加大小
1.延迟加载尽可能多的已编译应用程序（改善初始启动）
1.不要使用会增加额外大小的第三方库
1.请确保您使用dotnet 8
1.压缩一切 *（在合理范围内）
1.在网站加载后手动启动Blazor（当用户正在阅读所有可爱的静态内容时）
看看QuickGrid演示站点--我的加载时间约为400毫秒https://aspnet.github.io/quickgridsamples/