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

创作场景

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