Http2 x http1 benchmark

[Farenheith]

Hi, I was just exploring some benchmarks to try to justify at my company whether or not to use http2 in internal microservices. We're also in a movement to remove axios usage and adopt native fetch.

Of course, http2 can only be achieved with native fetch right now by using undici agent, but soon it'll be native as well (Node 26).

All that said, I created the following benchmark:
http2-benchmark-undici.js

The results were partially unexpected for me:

• undici beat axios by far with http 1.1
• Axios beat undici by 10% with http 2

📊 Comparisons (using median times):

--- axios HTTP/2 vs HTTP/1.1 ---
  ✓ HTTP/2 is 93.98% faster

--- undici vs axios (HTTP/2) ---
  ✗ undici is 10.30% slower

--- Ranking (HTTP/2 only, median times) ---
  🥇 1. axios: 27.60ms ±8.44ms (baseline)
  🥈 2. undici: 30.44ms ±6.83ms (+10.30%)

--- Ranking (HTTP/1.1 only, median times) ---
  🥇 1. undici: 40.31ms ±477.71ms (baseline)
  🥈 2. axios: 458.16ms ±403.98ms (+1036.49%)

--- HTTP/2 vs HTTP/1.1 Improvement (per client) ---
  axios: 93.98% faster with HTTP/2 (27.60ms vs 458.16ms)
  undici: 24.48% faster with HTTP/2 (30.44ms vs 40.31ms)
✅ Benchmark completed!

I even tried to quickly write a custom Agent for Undici, but this is not so trivial, so I hung that possibility for later.

Axios setup for http2 was the default one, just setting up httpVersion, while undici agent I've set up like this:

   new undici.Agent({
      allowH2: true,
      connections: 1,
      maxCachedSessions: 10,
      pipelining: 1024
    });

I've tried to find a configuration where I could extract most of undici, but the most relevant one for this test was to set up connections to 1, removing pool overhead.

This is not a problem with the lib. Performance is consistently better with much less variance in response time when using http2 compared to http1, as expected, and this still justifies trying that out with my colleagues, but I wonder if there's room for improvement in HTTP/2 requests, or if this difference is justified by extra security measures undici takes

[metcoder95]

can you provide a repo with the benchmarks you are attempting?
There are optimizations that can be done, for sure; but wondering your setup currently.

[Farenheith]

I'll prepare one this weekend! But It consists just in the provided js file with latest undici and axios version installed. I'm running it on latest NodeJs 24, too.

Also, I took a look at both, axios and undici http2 conn management. Axios does not use a connection pool, at least at first glance. That's why I've setup undici to 1 connection, so it wouldn't pool conns, too. That was the best setup I could figure out for this bench.

Finally, I've ran it in inside wsl. I'll run it in a pipeline after I create the repo you asked to see if my local machine affects the bench anyhow

[Farenheith]

@metcoder95 I've created the repository as requested. Resutls keeps consistent between node versions: undici beat axios by a large difference when using http1, but http2 axios is consistently faster

https://github.com/Farenheith/undici-benchmark/actions/runs/24944781831/job/73044257456

[metcoder95]

The @mcollina's summarizes the anaylisis, thanks for the repo 👍

[mcollina]

Thanks for putting together the repro repo — I took a closer look and one thing stands out immediately on the Undici side:

undici.fetch() is being called with a new AbortController() for every request:

get: (url) => {
  const controller = new AbortController()
  return undici.fetch(url, {
    method: 'GET',
    dispatcher: undiciAgentH2,
    headers: new Headers({
      Connection: 'keep-alive'
    }),
    signal: controller.signal
  }).then((result) => {
    if (!result.ok) throw new Error(`Request failed with status ${result.status}`)
    return result
  }).then((res) => res.text())
}

Axios is not doing the equivalent in this benchmark. The repo just calls axiosClient.get(url) without passing a signal/cancel token, so this adds per-request JS allocation/setup overhead only on the Undici path.

I tried a reduced harness with the same basic H2 workload, but changing the Undici calls as follows:

Current repo-style Undici fetch

await undici.fetch(url, {
  dispatcher: agent,
  headers: new Headers({ Connection: 'keep-alive' }),
  signal: new AbortController().signal
})

Minimal Undici fetch

await undici.fetch(url, {
  dispatcher: agent
})

Undici request

await undici.request(url, {
  dispatcher: agent
})

In my runs, the results looked like this:

• axios h2: 73.64ms
• undici.fetch h2 (repo-like): 86.12ms
• undici.fetch h2 (minimal): 74.00ms
• undici.request h2: 59.54ms

So just removing the extra per-request setup on the fetch() path — especially the unused AbortController allocation — made the gap between Axios h2 and Undici h2 mostly disappear in my tests. And using undici.request() was faster still.

That’s why I’d be careful about reading the current repo result as:

“Undici HTTP/2 is slower than Axios HTTP/2”

What it seems to show more specifically is:

“In this localhost microbenchmark, the current Undici benchmark path includes extra per-request fetch setup work that Axios does not.”

One especially important point is that the AbortController is never actually used to abort anything here, so it is pure hot-path setup cost in this benchmark.

Also, I checked connection usage on the H2 side: both clients were using 1 HTTP/2 session with 300 streams, so this does not appear to be a connection-count difference. The asymmetry in per-request setup looks like a more plausible explanation for at least part of the delta.

I think a useful next step would be to benchmark these three side by side in the repo itself:

1. current repo-style undici.fetch(...)
2. minimal undici.fetch(...)
3. undici.request(...)

That would help separate fetch-layer overhead from transport performance.

[Farenheith]

@mcollina, thank you for your feedback about my benchmark.

AbortController was used because axios offers timeout control in its external api, so I wanted to make a fair comparison between both as handling request timeout is essential in most cases, but indeed I was using the wrong tool for the job; I should've used AbortSignal directly. Fixed it.

Keep-alive headers are also pointless when using http2, so I removed it, too, from all h2 cases.

I've also improved the benchmark, adding the cases you suggested. Here are the new results:

https://github.com/Farenheith/undici-benchmark/actions/runs/24960277630/job/73085633502

  🥇 1. undici (request + abortSignal): 20.73ms ±5.76ms (baseline)
  🥈 2. undici (request): 21.05ms ±3.41ms (+1.54%)
  🥉 3. undici (minimal): 32.96ms ±7.35ms (+58.97%)
  🥉 4. axios: 35.01ms ±6.37ms (+68.88%)
  🥉 5. undici (fetch): 37.78ms ±6.81ms (+82.22%)

What bugged me a little bit is that request + AbortSignal is consistently better than pure request, which doesn't make any sense, as minimal fetch is faster than axios, and fetch + AbortSignal is slower.

So, I've changed another thing: I've removed method: 'GET' from the current undici fetch test. I think it doesn't make any sense for it to increase the benchmark time, but there wasn't anything left to remove.

The results are still the same.

https://github.com/Farenheith/undici-benchmark/actions/runs/24960556515/job/73086342693

  🥇 1. undici (request + abortSignal): 18.86ms ±5.89ms (baseline)
  🥈 2. undici (request): 19.44ms ±3.54ms (+3.03%)
  🥉 3. undici (minimal): 31.60ms ±8.37ms (+67.51%)
  🥉 4. axios: 33.70ms ±5.94ms (+78.63%)
  🥉 5. undici (fetch): 34.50ms ±10.66ms (+82.86%)

So, somehow AbortSignal has some impact in fetch, but in request, it makes it a bit faster? I know the difference is marginal, but I've rerun this many times locally, and the rank doesn't change.