但目前没有任何数据证明,“更快”也只是字面含义。
幸运的是,我有一个在 Node 6 上运行的大好 React 网站,并且正好有两个小时业余时间。
升级到 Node 8 是相当容易呢-只花了大约十分钟,并且没有一个依赖库落下。我从这个网站找到 .pkg 文件安装到我的 macOS 上面,还算顺利,但我需要手工删除 /usr/local/lib/node_modules/。
一切顺利进行,我之后可能会在 Windows 机器上尝试,但会需要四天时间。
注:谢天谢地,在 Windows 升级就像做梦一样。不用手工操作,没有失败的包安装,没有看到任何之前这个网页提到的白热化的问题。
网站
这些性能比较适用于具有单页面中等规模的 React 站点。在服务器上,它需要一个具有数千个属性的 JSON 对象,并返回具有 2113 个 DOM 节点的 HTML。
(是的,这确实有太多的 DOM 节点。只需要两秒钟就可以在手机上完成解析。但可惜的是,我的知识链有限,对此无能无力。其中一半是隐藏的 ,只有“搜索引擎优化”对外开放,但这甚至不能让我入门。)
让我们开始试验吧。
服务器端渲染时间
我们从最重要的度量开始,即在服务器端渲染页面的时间。
测试是在一台相当大的银色笔记本中进行的,这台笔记本大概有 2GHz 的主频,运行着 macOS Sierra。
乍一看并没有多大的差异,但在第 8 次运行的时候,渲染时间稳定下来了。Node 6 大概用了 104ms,Node 8 用了大概 80ms。
减少 23% 的渲染时间,这是相当不错的成功。更具体地说,为网站服务节约了 23% 的硬件成本。
我准备建议我的老板更新到 Node 8,这会将我们在亚马逊租用的服务从25减少到20,第一个月节约出来的成本则用于捐助 Node.js 基金会。
因为我喜欢听到笑声。
下面是同一个测试,不过是在开发模式下使用 React:
除开前几次运行,(性能)平均降低了31%。这张真实的图表提醒人们把 NODE_DEV 设置为 `production`,并发布生产版本的库,是件非常重要的事情。
我不确定这种性能提升来自哪里。我估计主要来自于 V8 5.8。如果你对它如何工作有兴趣的话,这里有一个很棒的视频。
运行一套测试
这套大约 500 个 Jest 测试主要是关于装配和卸下 React 组件,很明显只与一般的 JavaScript 相关。
8 次运行的中值
减少 10%。也许这里的改进不那么明显,因为 JavaScript 引擎没有进行任何优化(每次运行都重新启动 Node)。这只是猜测,非常欢迎大家指正/解释。
Webpack构建
Webpack 构建是一些磁盘 I/O,一堆 Babel transpiling、JS uglifying/minifying 构成的,大约有 500KB 的 JavaScript。
对此不多说了。大约在运行时间上减少 7%。
NPM install
现在切换到 Windows,这个最常用 NPM 的操作系统(OS)(手工切换)。硬件是大的矩形机器,拥有黑色绒面内饰,闪烁各不少霓虹灯。
package.json 中声明了 40 个包,完整的依赖树还包括 445 个包。
为得测得第一手数据,我删除 npm 缓存以及项目目录下的 node_modules 目录,所以测试需要从互联网上获取包。
很有意思,NPM 3 突破了 7 Mbps 的下载速度,而 NPM 5 则达到了 20 Mbps。
为了好玩,我也用 yarn 来测试了。
顺便给写这个消息的人说两句:
…你有点把我逗乐了。这是一个神经质的笑话,因为我不知道在干什么,正如 Marcel Marceau 所说。
接下来,我运行了 npm install,在有 npm 缓存,但是删除了 node_modules 的情况下,我认为主要的工作是磁盘 I/O (从缓存拷贝到项目目录),但是显著的时间提升表明不止干了那些事情。
两种情况下,NPM 5 减少了约三分之一的时间。而且两种情况下,yarn 都快得多(我并不需要切换过去,但是,有人需要)。
这就是我所有图表,亲们。
说实话,我认为用 Node 8 也许能优化几个百分点的性能,但如果理想没有变成现实也不要惊讶。不管怎么说,减少了四分之一的服务端渲染时间和三分之一的 NPM install 时间也很不错了。
干得好,每一位做出贡献的人。干得非常棒。
哦,还有新特性。