但目前没有任何数据证明，“更快”也只是字面含义。
幸运的是，我有一个在 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 时间也很不错了。
干得好，每一位做出贡献的人。干得非常棒。
哦，还有新特性。
