Web Worker 通信性能研究：通过多线程改进 Web 应用性能

Surma 是谷歌的 Web 布道师，最近发布了一项有关 postMessage 的性能研究结果。postMessage 是 Web Worker 的通信方式。Surma 的结论是，虽然 postMessage 会带来一些开销，但如果有效载荷低于给定的开销预算，那么将非 UI 任务移出主线线可能会提高总体性能。

超过一半的互联网接入来自手机或平板电脑，而低端多核移动设备的市场份额一直在增加，Web 应用程序开发人员必须确保应用程序在低配置的环境中（如慢 CPU、GPU 或小内存）也能具有高性能。

在这种情况下，使用多线程的 Web Worker 可以将与计算相关的负载从主执行线程中隔离出来。最终的性能是在原生多核心架构上并行化任务（如果可用）所带来的好处加上与线程间通信开销相关的成本的总和。对于 Web 应用程序来说，主要的通信开销是使用 postMessage 方法在主 UI 线程和 Web Worker 之间进行通信。

由于一些开发人员不愿使用 Web Worker, Surma 对 postMessage 的性能做了一些说明。Surma 解释了他的研究背后的缘由：

人们不会考虑使用 Web Worker，是因为他们担心 postMessage（）的性能，所以这是值得研究的一件事情。

该研究包括两个基准。第一个基准测试分析了在线程之间发送消息所需的时间，并显示了它与所发送的对象的复杂性之间的正相关关系。

第一个基准测试分别在 2018 款 MacBook Pro 上的 Firefox、Safari 和 Chrome 上运行，在 Pixel 3XL 的 Chrome 上运行，在诺基亚 2 的 Chrome 上运行。对象复杂度是指表示对象的 JSON 树的深度（树的层次）和宽度（属性的数量）的组合。

第二个基准测试证实了与 JSON.stringify()返回的字符串长度的强正相关关系，不过带有一些警告。Surma 解释说：

我认为这种相关性足够强，我们可以从中得出一个法则：对象的字符串化 JSON 表示与它的传输时间大致成正比。但更重要的是，这种相关性只适用于大对象，我说的大对象是指超过 100KB 的对象。虽然这种相关性在数学上是成立的，但这种差异对于较小的有效载荷来说更为明显。

Surma 根据响应动画空闲加载（RAIL）指南给出了“慢”的定义，并对涉及 JS 驱动动画的上下文（显示下一帧的预算为 16ms）和不涉及上下文（响应用户交互的预算为 100ms）的情况进行了区分。

Surma 总结道：

即使在最慢的设备上，你也可以使用 postMessage()发送 100KB 的对象，并保持在 100ms 的响应预算之内。如果有 JS 驱动的动画，有效载荷达到 10KB 是没有问题的。对于大多数应用程序来说，这应该足够了。使用 postMessage()确实有一定的代价，但不至于会导致脱离主线程架构变得不可用。

对于 postMessage 成本超过在多个线程上运行任务的好处的情况，Surma 提供了替代方案，比如通过使用分块技术或 WebAssembly 来提升性能。

完整的研究结果可以在 Surma 的博客上找到，其中包含了数据、可视化演示和图表。

原文链接：

Improving Webapp Performance With Multi-Threading: A Study of Web Workers’ Communication Overhead