Upgrading from Node 6 to Node 8: a real-world performance comparison

June 2nd 2017
Author profile picture

@david-gilbertsonDavid Gilbertson

Twitter social icongithub social icon

Node 8 is out, did you hear? And it’s faster, or so they say.

But without any numbers, ‘faster’ is just letters.

Luckily, I have a big fat React site running on Node 6, and two hours to spare.

It was easy enough to upgrade to Node 8 — it took about 10 minutes, with not a single broken library. I installed on macOS with the .pkg file from the website, and it was relatively smooth sailing. Although I did need to manually remove usr/local/lib/node_modules/.

All well and good, but I’ll try it later on my Windows machine and it will probably take four days.

Edit: holy crap, it worked like a charm on Windows. No manual steps, no broken packages, none of the white hot mess required not so long ago.

The site

These performance comparisons are for a medium-to-large React site with a single page. On the server, it takes a JSON object with a few thousand properties and returns HTML with 2113 DOM nodes.

(Yes, that is far too many DOM nodes. Yes, it does take two seconds just to parse it on a phone. But alas, I am too far down the food chain to do anything about it. Oh and half of those are hidden, only there “for SEO” — don’t even get me started.)

Let the time trials begin.

Server rendering time

Let’s start with the most important metric, the time taken to do the server rendering of the page.

Times are on a largish silver laptop that I think has a couple of GHz of buzz and macOS Sierra.

At first glance, not a massive difference, but by the eighth run, the render time settles down and Node 6 was getting the job done in about 104ms. Node 8 was taking about 80ms.

That’s a pretty decent 23% reduction in render time. Or, more concretely, a 23% reduction in the hardware required to serve the site.

I’m going to suggest to my employer that we upgrade to Node 8, reduce our Amazon instances from 25 to 20 and donate the first month’s savings to the Node.js Foundation.

Because I enjoy the sound of laughter.

Here’s the same test, but using React in dev mode:

After the first few runs, there was an average reduction of about 31%. This chart is really just here to remind people that it’s important to set NODE_ENV to ‘production’ and ship the production versions of libraries.

I’m not sure exactly where this performance boost is coming from. I expect largely from the bump to V8 5.8. Here’s a great video if you’re interested in how it all works.

Running a test suite

This suite of ~500 Jest tests mostly involves mounting and un-mounting React components, and obviously just general JavaScriptery.

The median of 8 runs

A 10% reduction. Perhaps the improvement is less pronounced here because the JavaScript engine isn’t doing any optimizations (each run was a fresh start of Node). That’s just a guess, corrections/explanations are most welcome.

Webpack build

The Webpack build is a little bit of disk I/O, a bunch of Babel transpiling, JS uglifying/minifying, all for about 500 KB of JavaScript.

Not much to say about this one. A 7% reduction in run time.

NPM install

Switching to Windows now, the most commonly used OS for NPM (by humans). Hardware is a big rectangular machine a black suede interior and more neon than I would like to admit.

There’s 40 packages in package.json; 445 packages all up in the dependency tree.

For this first set of numbers, I removed the npm cache and my project’s node_modules directory, so the test is fetching the packages over the internet.

Interestingly, NPM 3 topped out at about 7 Mbps download, with NPM 5 reaching 20 Mbps.

I’ve thrown in yarn for the fun of it.

As an aside, to whoever wrote this message:

…you got a little chuckle out of me. It was a nervous chuckle because I have no idea what I’m doing, but as Marcel Marceau once said

Next up, I ran npm install with the npm cache primed but node_modules removed between each run. I thought this would be mostly disk I/O (copy from the cache to the project directory), but obviously there’s more to it than that, as indicated by the significant improvement in times.

In both these scenarios, NPM 5 shaves off about a third of the install time. And in both cases, Yarn is significantly faster (not worth the switch for my needs, but hey, to each their own).

That’s all the charts I’ve got, folks.

To be honest, with Node 8 I was expecting an improvement of maybe a few percent, and wouldn’t have been surprised if that didn’t translate into the real world. But shaving a quarter off server-rendering time and a third off NPM install time is amazing.

Well done, everyone involved. Well done indeed.

Oh and there’s new features too.



The Noonification banner

Subscribe to get your daily round-up of top tech stories!