Blazor 性能

每次页面加载时浏览器都需要下载 WebAssembly 库是真的吗？

不，浏览器可以缓存文件。 Blazor 应用程序的通用 CDNs 可以解决问题。

这个系统是否比用 JavaScript 编译的 React / Vue.js 更快？

Blazor 使用 WebAssembly，理论上 WebAssembly 应该比任何 JavaScript 库都快。然而，并不是所有的浏览器都有成熟的 WebAssembly 解析器。因此，您可能会发现浏览器目前无法以最佳速度运行 WebAssembly。

您可以创建一个小型 Blazor 应用程序并在 Firefox、Chrome 或 Edge 中运行它。在大多数情况下，Firefox 运行 Blazor 应用程序的速度比 Chrome 或 Edge 快得多，这意味着浏览器制造商仍然需要改进，甚至 Firefox 也可以改进。

如果您的应用程序需要频繁访问 DOM，那么与任何 JavaScript 库相比，WebAssembly / Blazor 肯定会更慢，因为 WebAssembly 无法在不使用 Invokes 的情况下直接访问 DOM（目前速度很慢。请参阅我的 Blazor 基准测试以下）。

在 Firefox 上，对空方法的 10,000 次 RegisteredFunction.InvokeUnmarshalle 调用需要 250 ms，而 Chrome 和 Edge 在我的 PC 中需要超过 2400 ms。在纯 JavaScript 中，相同场景所需的时间不到 10 毫秒。

此外，Blazor 的当前实现在浏览器的 WebAssembly 引擎之上有自己的 MSIL 引擎，这意味着有两个解释器在工作来运行 Blazor 项目，就像两个翻译器在一个对话中解释对话一样。目前，Microsoft 正在开发尚未发布的 AOT 编译器。一旦发布，Blazor 将比当前的实现快得多。

Mono and WebAssembly - Updates on Static Compilation

我们可以有把握地假设 Web 程序集是 Web 开发的未来，但目前我们还不能说 Blazor 的未来。从理论上讲，Blazor 可以比现有的任何框架都快，但是我们需要 WebAssembly 维护者、浏览器开发人员、微软和社区的承诺，以使理论变得实用。

2018 年 7 月 10 日更新

WebAssembly 存储库中有新的提议。

允许 WebAssembly 直接处理 DOM。接口类型 #8 WebAssembly 与 GC 的参考类型。 WebAssembly 的引用类型

上述两个提议将为未来 DOM 和 WebAssembly 之间更快的交互铺平道路。换句话说，Blazor 未来会更快。

2018 年 10 月 17 日更新

Firefox 团队能够以与 JavaScript 到 JavaScript 方法调用一样快的速度实现 JavaScript 到 WebAssembly 调用。到目前为止，在 WebAssembly 支持方面，Firefox 远远领先于任何其他浏览器。

Calls between JavaScript and WebAssembly are finally fast

---

2021 年 4 月，我们针对旧版 Angular.js Web 应用程序以及 Flutter Web（HTML 和 CanvasKit 渲染器）进行了 Blazor WASM 试验。我们重新创建了旧版应用程序的主页（本质上是一个带有过滤器、分页、排序等的大数据网格）。这里有一些要点：

                                                                      Lighthouse perf. Scores
                   Grid Displ.  Data transf.  Data uncomp.  Reqs.  FCP   SI   LCP  TTI  TBT  CLS
Blazor*            2.2s         4.7MB         13.7MB        99     0.5s  1.6s 0.5s 2.1s 1.3s 0.01 
Flutter HTML       1.7s         2.1MB          3.7MB        15     1.9s  2.5s 2.2s 2.3  0.2s 0
Flutter CanvasKit^ 2.8s         4.7MB         10.5MB        17     1.0s  2.2s -/-  2.2s 1s   0   
AngularJS`         1.9s         2.0MB          5.7MB        294    2.1s  2.2s 2.6s 2.6s 0.1s 0

网格显示- 完全显示网格所需的时间（从时间线和 Lighthouse 收集的屏幕截图来看）

数据传输- 加载应用程序时传输的数据（DevTools 中的网络选项卡，清除缓存）

数据未压缩。 - 传输数据的未压缩大小（网络选项卡）

要求。 - 加载应用程序时发出的请求数（网络选项卡，清除缓存）

灯塔性能得分明细

在 Windows 10、Google Chrome 版本 89.0.4389.128（官方版本，64 位）、Intel Core i5 4460、16GB RAM、有线 LAN 连接上测试

用于构建应用程序的发布配置、Blazor WASM/.NET 5、Flutter（Channel beta，2.1.0-12.2.pre）、AngularJS 1.7.7

*Lighthouse 给出的 LCP 值不正确（它将 Blazor 的空白“正在加载...”页面计为 LCP）

^Flutter 的 CanvasKit 渲染器不允许 Lighthouse 进行 LCP 测量

`遗留应用程序比创建的 PoC 大得多，有更多的屏幕和资产会影响应用程序启动时的请求数量

---

据我了解，Blazor 使用 WebAssembly 在客户端编译 C#。

对了一半。您可以将代码写入 WebAssembly (WASM) 客户端（是的，客户端是 C#），但您也可以执行逻辑服务器端。两者都有好处。如果你走 WASM 路线，你的所有代码都是可见的。但它可以比逻辑全部基于服务器的情况更快地重新呈现——但如果它是基于服务器的，则您的代码是不可见的。

这种方法是否比用 JavaScript 编译的 React / Vue.js 运行得更快？

不。我已经完成了大量的 Vue.js 并且 Vue.js 运行得更快。 但是我可以使用 Blazor 更快地编写代码 很多。 Blazor 提供了一种虚拟滚动解决方案，可以让它看起来更快。在我的情况下，可用的绘图组件太慢了。我使用 C# 和 JavaScript 编写了一个运行良好的 Blazor 组件。大多数时候我不担心 WASM 代码运行太慢……但绘图需要更快……Blazor 让我有我的蛋糕……我只需要在JavaScript。在过去六个月中，Blazor 的执行速度越来越快，该团队表示，当 .NET 6 出现时，还有更多的事情要做。但这对于我需要做的 99% 的事情来说已经足够快了。

每次页面加载时浏览器都需要下载 WebAssembly 库是真的吗？

如果它们被缓存，则不会。即使他们第一次加载，如果你有一个体面的连接，它也不会很慢。它大约为 10 MB。

一个没有被问到的大问题——它值得使用吗？我已经使用它大约六个月了。

对我来说，这很棒。 C# 是一门非常好的语言。有时我会错过动态添加属性，并且通常您必须手动启动重绘，但使用可空对象检查等功能会警告您没有检查您的代码是否会导致空引用检查——它比 JavaScript 好得多。我经常觉得使用 JavaScript“工具链”很痛苦。能够选择退出 JavaScript 库的混乱真是太好了。

---

.NET 6 的 ASP.NET Core 路线图可在 github here 上找到。您会发现 Blazor 的任务最多。

请注意，该列表表明 ASP.NET 团队将重点关注的项目意味着他们将重点放在改进 Blazor 上。

本期代表了我们团队在 .NET 6 时间范围内将重点关注的主要投资清单。此列表中的项目仅是主要投资领域，不包括我们将在此期间解决的所有功能和错误修复。

以下是他们一直在从事的一些任务：

完成的任务：

AOT 编译。将所有内容编译到 WebAssembly 改进 Blazor 中的 SVG 支持。 Blazor 中 SVG 支持的顶级问题 支持 JS 互操作中的字节数组传输。

正在进行的任务

Blazor 的热重载。构建性能优化暂停和恢复 Blazor 应用程序。定位并部署到桌面平台。删除 SignalR 消息大小施加的大小限制。拖放。提供用户可以在拖放过程中订阅的事件

---