Upgrading from Node 6 to Node 8: a real-world performance comparison
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
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.
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
The median of 8 runs
Not much to say about this one. A 7% reduction in run time.
Switching to Windows now, the most commonly used OS for NPM. 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.