Node 16 VS Node 22 Performance

[759325100]

I want to upgrade my project from Node v16.19.1 to Node 22.13.1, before upgrading I did a benchmark to measure performance changes after the upgrade (http server)

But I got a bad result. The performance of Node V22 has a significant decline compared to Node V16 (specifically referring to http scenarios)

Below is the environment and results of my test. I hope you can get your answers. Thank you.

Docker run node v22.13.1 alpine(3.20) on centos7(8cpu 16G)
Docker run node v16.19.1 alpine(3.12) on centos7(8cpu 16G)

Docker run script (The contents in the docker image are basically the same)

docker run --name=node-v22 --rm -it -p 30255:3000 dockerhub.xx/node:22.13.1 /bin/ash
docker run --name=node-v16 --rm -it -p 30256:3000 dockerhub.xx/node:16.19.1 /bin/ash

create app.js content

const http = require('http');

// create HTTP server
const server = http.createServer((req, res) => {
  // set response header
  res.writeHead(200, { 'Content-Type': 'text/plain' });

  // send "Hello World" to client
  res.end('Hello World');
});

// listen 3000 port
server.listen(3000, () => {
  console.log('Server running at http://localhost:3000/');
});

run

node app.js

Throughput testing using abtest.

# n = 1000 or 2000
ab -n 100000 -c n http://localhost:30256/

# n = 1000 or 2000
ab -n 100000 -c n http://localhost:30255/

Test Result

Node V16 2000 concurrent

Server Software:
Server Hostname:        localhost
Server Port:            30256

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      2000
Time taken for tests:   26.451 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11200000 bytes
HTML transferred:       1100000 bytes
Requests per second:    3780.59 [#/sec] (mean)
Time per request:       529.018 [ms] (mean)
Time per request:       0.265 [ms] (mean, across all concurrent requests)
Transfer rate:          413.50 [Kbytes/sec] received

Node V22 2000 concurrent

Server Software:
Server Hostname:        localhost
Server Port:            30255

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      2000
Time taken for tests:   51.655 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11200000 bytes
HTML transferred:       1100000 bytes
Requests per second:    1935.93 [#/sec] (mean)
Time per request:       1033.096 [ms] (mean)
Time per request:       0.517 [ms] (mean, across all concurrent requests)
Transfer rate:          211.74 [Kbytes/sec] received

Node V16 1000 concurrent

Server Software:
Server Hostname:       localhost
Server Port:            30256

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      1000
Time taken for tests:   23.729 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11200000 bytes
HTML transferred:       1100000 bytes
Requests per second:    4214.23 [#/sec] (mean)
Time per request:       237.291 [ms] (mean)
Time per request:       0.237 [ms] (mean, across all concurrent requests)
Transfer rate:          460.93 [Kbytes/sec] received

Node V22 1000 concurrent

Server Software:
Server Hostname:        localhost
Server Port:            30255

Document Path:          /
Document Length:        11 bytes

Concurrency Level:      1000
Time taken for tests:   32.905 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11200000 bytes
HTML transferred:       1100000 bytes
Requests per second:    3039.03 [#/sec] (mean)
Time per request:       329.052 [ms] (mean)
Time per request:       0.329 [ms] (mean, across all concurrent requests)
Transfer rate:          332.39 [Kbytes/sec] received

I've tested it many times and the results are basically the same.

Can anyone tell me the reason or a more standard test method.

From the perspective of resource consumption, the Node V22 memory usage is smaller, but the CPU has reached a peak of 100% during the test.

Thank for everyone

[muhammedajsalk]

he performance gap between Node.js 16 and Node.js 22 is quite significant because of improvements introduced over several major releases. Here are the main reasons why Node 22 generally outperforms Node 16:

1. V8 Engine Upgrades
   Node 16 uses V8 9.x, while Node 22 ships with V8 12.x.

This means:

Better JIT optimizations → Faster execution of JavaScript, especially for heavy loops and async operations.

Improved garbage collection → Reduced memory overhead and GC pauses.

New language features and micro-optimizations in the engine.

2. Event Loop & Async Improvements
   Node 18+ introduced improved timers and event loop scheduling, reducing latency in high-concurrency environments.

Node 22 benefits from better async context handling, which reduces overhead when using async/await or Promises.

3. Native Fetch, Web Streams, and URL APIs
   Node 16 relies on polyfills or external libraries for these features.

Node 18+ and Node 22 include native implementations → lower overhead, better performance in HTTP-heavy applications.

4. Better HTTP/2 and HTTP/3 (QUIC) Support
   Node 16’s HTTP/2 implementation was still experimental and less optimized.

Node 22 includes stability improvements and faster networking stack, especially for streaming and large payloads.

5. Startup and Memory Usage
   Node 22 has faster startup time due to internal optimizations and reduced bootstrap cost.

Lower memory fragmentation and improved heap management lead to better performance for long-running apps.

6. Security and Tooling
   Node 22 supports built-in test runner, native fetch, and Permissions Model, which can reduce dependency on third-party tools (fewer layers = faster).

Enhanced diagnostics and profiling tools help optimize performance in production.

Benchmarks
Real-world benchmarks show Node 20/22 can be 15–30% faster in compute-heavy and I/O-bound workloads compared to Node 16.

Native Fetch and improved streams alone make a noticeable difference in API servers.

Bottom Line
If your application relies on:

High concurrency

Heavy async operations

Modern JavaScript features

Then upgrading from Node 16 → Node 22 is a big win for performance and maintainability. Plus, Node 16 is already in Maintenance LTS, so you get security and long-term stability by upgrading.

Recommendation: Upgrade to Node 22 (or latest LTS) unless you have a specific dependency requiring Node 16. The performance, security, and DX improvements are worth it.

[Felipeness]

Your benchmarking setup is the problem, not Node 22.

ab (Apache Bench) is notorious for producing unreliable results with Node.js — it has known issues with connection reuse and HTTP/1.1 keep-alive handling. Switch to autocannon (written by a Node.js core collaborator) or wrk and you'll likely see a much smaller gap:

npx autocannon -c 1000 -d 30 http://localhost:30255/
npx autocannon -c 1000 -d 30 http://localhost:30256/

Two other things going on here:

V8 warmup. Node 22 ships with V8 12.x and the Maglev tiered JIT compiler. It needs warmup time before reaching peak performance. With short benchmarks you're measuring compilation time, not steady-state throughput. Run a warmup phase of 10-15 seconds before you start collecting numbers.

Docker networking is adding noise. You're running both containers with port mapping (-p) on CentOS 7, which uses an older kernel with iptables-based Docker networking — that adds variable latency. For a fair comparison, either run ab/autocannon inside the same container, test on bare metal, or use --network=host.

There's also the fact that your Alpine base images are significantly different — Alpine 3.12 (Node 16) vs Alpine 3.20 (Node 22) ship different musl libc versions and system libraries, which alone can affect I/O performance.

Worth noting: Node 22 does have a stricter HTTP parser (llhttp enforces stricter RFC compliance — header validation, chunked encoding rules, etc.), which adds some per-request overhead. You can test its impact with --insecure-http-parser to isolate how much of the gap comes from that.

But honestly, hello-world HTTP benchmarks amplify per-request overhead because there's zero application logic. In a real app with database calls, serialization, and business logic, that overhead becomes negligible. V8 12.x's GC and memory management improvements actually tend to improve performance under sustained real-world load.

Re-run with autocannon, add a warmup phase, and test on bare metal. The gap should shrink significantly.

[avivkeller]

@Felipeness please stop sending artificially generated answers. Many people are looking for human insight, not 🤖

[Felipeness]

@Felipeness please stop sending artificially generated answers. Many people are looking for human insight, not 🤖

@avivkeller Fair point... I’ve been using AI to help me write in English since it’s not my first language. Probably overdid it on the formatting. The technical content is mine though, happy to discuss any of it.