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.

[pacocartones]

I cloned Farenheith/undici-benchmark and ran it as-is, three times (median of 40 runs each): Node v24.14.1, axios 1.15.2, Windows; undici 8.1.0 (lockfile) for the first two runs and 8.10.0 for the third. I could not reproduce "axios beats undici on HTTP/2" — quite the opposite:

--- Ranking (HTTP/2 only, median times) ---   run 1 (8.1.0)  run 2 (8.1.0)  run 3 (8.10.0)
  undici (request)                            27.44ms        31.82ms        23.60ms
  undici (request + abortSignal)              28.73ms        28.87ms        29.12ms
  axios                                       49.93ms        82.73ms        44.52ms
  undici (minimal, fetch)                     54.11ms        44.92ms        46.00ms
  undici (fetch + AbortSignal.timeout)        64.08ms        51.19ms        62.84ms

Two things stand out:

1. The "undici" number in the original report is measured through fetch() (undiciFetch(url, { dispatcher }) + res.text()). In your own benchmark, undici.request is consistently ~1.6–2× faster than the fetch-based variants against the same Agent and the same h2 session. So the ~10% delta you saw is fetch-API overhead (Headers/Response construction, body consumption via the web streams pipeline), not the HTTP/2 implementation. If the decision at your company is "native fetch vs axios", that overhead is real and worth measuring — but if the question is "is undici's h2 slower than axios's h2", the protocol-level answer here is no.

2. axios's h2 path is a thin wrapper: axios/lib/adapters/http.js keeps a simple per-authority cache of raw http2.connect() sessions (1 s idle timeout) and issues plain stream requests — no fetch semantics at all. That's a reasonable design, but it means the comparison "axios vs undici.fetch" is really "raw h2 streams vs the full fetch pipeline".

Caveats on my runs: the HTTP/1.1 legs were noisy on Windows (300 concurrent sockets hit ECONNREFUSED bursts, likely ephemeral-port pressure — the undici h1 medians of ~0.9–1 s include retried connections), so I wouldn't read much into h1 numbers from either of our setups without pinning down failure counts. The h2 ranking above was stable across both runs and both undici versions I tried (8.1.0 and 8.10.0 — same ordering).

If you want a like-for-like h2 measurement, I'd suggest adding one more client to the matrix: undici.request against your axios h2 client, both consuming the body, and reporting failure counts alongside medians. Happy to send a PR to your benchmark repo with that variant if useful.

[Farenheith]

Thank you for trying that out. You ran it directly on windows, right?

Maybe I got different results because I was running it on wsl? I have a Ubuntu machine right now, I'l re-run the project to see if there are any differences.

Feel free to send a pr, btw. I'll appreciate it

[Farenheith]

So, I've run it on my new Ubuntu machine; here are the results:

--- Ranking (HTTP/2 only, median times) ---
  🥇 1. undici (request): 13.10ms ±2.27ms (baseline)
  🥈 2. undici (request + abortSignal): 13.54ms ±1.88ms (+3.31%)
  🥉 3. axios: 19.77ms ±4.10ms (+50.87%)
  🥉 4. undici (minimal): 20.75ms ±4.45ms (+58.34%)
  🥉 5. undici (fetch): 24.21ms ±6.44ms (+84.78%)

--- Ranking (HTTP/1.1 only, median times) ---
  🥇 1. axios: 78.55ms ±39.15ms (baseline)
  🥈 2. undici (fetch): 501.35ms ±816.16ms (+538.25%)

--- HTTP/2 vs HTTP/1.1 Improvement (per client) ---
  axios: 74.83% faster with HTTP/2 (19.77ms vs 78.55ms)
  undici (fetch): 95.17% faster with HTTP/2 (24.21ms vs 501.35ms)

I need to point out something I noticed after looking at your results: The result you found actually aligns with mine.

The first version of this benchmark was testing axios vs fetch, not undici.request. After @mcollina feedback, I've added request to the benchmark, and this option was already beating axios, as you can see here.

See that comparing pure undici.request with axios is not fair, because axios does a lot of important things that request does not, like header validation to avoid some sort of attacks and timeout control.

Your results, so, are very similar to the latest one I shared.
Still, the part that is "fair", even in your results, showed axios winning:

  axios                                       49.93ms        82.73ms        44.52ms
  undici (minimal, fetch)                     54.11ms        44.92ms        46.00ms

Keep in mind, though, that using undici.request is very safe on the server side, so giving up some security controls where you know you're not exposed to such attacks is totally acceptable, and this is the fastest option we have for that scenario

[pacocartones]

Hi @Farenheith — thanks for the reply! Yes, my runs were on native Windows (Node v24.14.1, Git Bash). Appreciate you re-running on your Ubuntu box; the h2 ordering held across undici 8.1.0 and 8.10.0 on my side, so it will be interesting to see if WSL changes the h1 picture too.

And yes — PR sent: Farenheith/undici-benchmark#1. It adds request failure counting alongside the medians (the h1 ECONNREFUSED bursts made those medians hard to trust), with a warning when either leg drops requests. The undici.request client is already in your matrix, so no new client was needed.

Happy to adjust the PR if you'd prefer the failures reported differently.

[pacocartones]

Circling back now that #1 has merged (thanks @Farenheith) — the request-failure counts it adds are exactly what make the HTTP/1.1 medians interpretable.

The h1 variance in this benchmark comes from ECONNREFUSED bursts: connections refused and retried, which a bare median silently mixes in with slow-but-successful responses. With the failure column, an h1 result now reads as "median X over N successful requests, M failures" instead of one number that hides both. That's the piece the original "axios wins h2 / undici wins h1" framing was missing — the h1 side wasn't apples-to-apples until the failures were separated out.

So the interesting next step is re-running the h2 comparison the same way: if the axios/undici gap there survives once refused-connection noise is isolated from genuine latency, it's a real difference worth digging into; if it moves around with the failure counts, it was measurement noise. Happy to help run that side by side.

[pacocartones]

Ran the merged benchmark (d1091ca) six times end to end — three on undici 8.1.0, three on 8.10.0. Windows 11, Node v24.14.1, axios 1.15.2, i7-11800H, 16 logical cores. Each execution is the repo's default matrix: 40 sampled runs per leg, 300 concurrent requests per run, so 12,000 requests per leg per execution.

Before trusting the counter I checked it against cases with a known answer: a closed port counts every request as a failure (60/60), a healthy server counts none, a server that 500s one request in seven reports exactly 8 of 60, and the h2 legs negotiate HTTP/2 while the h1 leg negotiates HTTP/1.1. One detail worth stating plainly, because it changes how the column reads: the "median time" is the median of the per-run wall clock for the whole 300-request batch, and failed requests sit inside that wall clock. It is not a median over successful requests.

HTTP/2: zero failures. Across all six executions and all five h2 clients, 0 of 360,000 requests failed. There is no refused-connection noise on the h2 side to separate out — those numbers were already measured over complete work.

HTTP/1.1: undici loses 22.67%, identically, every time.

                    failures per execution (of 12,000)
  undici h1   2720  2720  2720  2720  2720  2720    (22.67%)
  axios  h1     68   136   136    68   136    68

2720 is 68 x 40: exactly 68 requests refused per 300-request run, in six independent executions across two undici versions. A count that reproducible is not a burst.

The cause is connection reuse, not HTTP/1.1. The h2 legs pass an explicit undici.Agent; the h1 leg calls undici.fetch(url) with no dispatcher. Counting TCP connections server side over 5 batches x 300 requests:

  undici fetch, as in the repo             1160 req over 1160 conns   1.00 req/conn   68 failures every batch
  same, listen backlog raised to 4096      1160 req over 1160 conns   1.00 req/conn   68 failures every batch
  axios h1, as in the repo                 1432 req over  432 conns   3.31 req/conn   68 failures, first batch only
  undici.request, Agent({connections:10})  1500 req over   10 conns   150 req/conn     0 failures

Raising the accept backlog changes nothing, so it is not the listen queue. axios reuses sockets and pays the cost once, on the cold batch. Giving undici a pool removes the failures entirely and serves all 1,500. The h1 leg is comparing a client that opens a socket per request against one that does not; the protocol is not what is being measured there.

axios vs undici (minimal) on h2 — @Farenheith, this is the comparison you called the fair one. Over six executions, with zero failures on both sides, it is 3-3:

  axios median    95.4   79.6   50.8   81.6   71.9   54.8  ms
  undici minimal  73.7   82.5   80.6   50.9   45.7   63.1  ms
  delta          +22.7   -3.7  -58.9  +37.6  +36.5  -15.3  %   (+ = undici faster)

The same client's median moves by roughly 2x between executions on the same machine (axios 50.8 -> 95.4). That swing is larger than any gap being compared, so at 300 concurrency this harness cannot resolve a 10% difference on this hardware — the original "axios is 10.30% faster" sits inside its own noise. undici.request is the one result that survives: it beats axios in 5 of 6 executions, and request + AbortSignal in 6 of 6.

One correction on the stated reason for setting undici.request aside. It does validate headers and it does have timeout control:

undici.request(url, { headers: { 'x-foo': 'bar\r\nX-Injected: 1' } })
// InvalidArgumentError: invalid x-foo header
undici.request(url, { headers: { 'bad header name': 'v' } })
// InvalidArgumentError: invalid header key
undici.request(url, { headers: ['host', 'a', 'host', 'b'] })
// InvalidArgumentError: duplicate host header
undici.request(url, { headersTimeout: 300 })  // against a server that never responds
// HeadersTimeoutError UND_ERR_HEADERS_TIMEOUT after 339ms

CRLF in header values, invalid header names and duplicate host are all rejected in lib/core/request.js, and headersTimeout/bodyTimeout are per-request options. So the choice between undici.request and axios is not trading those protections for speed.

Two suggestions, if useful: give the h1 undici client an explicit Agent so both h1 clients have comparable connection behaviour, and treat any h2 difference under about 2x as unresolved at this concurrency.

Not verified: all of the above is one Windows machine. The 68-per-run refusal count is very likely OS specific and I would expect different absolute numbers on your Ubuntu box. The 1.00 vs 3.31 requests-per-connection asymmetry, though, is in the harness configuration rather than the OS, so it should reproduce there. The workflow has not been dispatched since April, so a CI run would now report the counts too.

[Farenheith]

@pacocartones, those are fair arguments, and I appreciate you investing your time in that analysis. I've run the bench workflow again; the results nowadays favor unidici on http2.

I added node 26 to the list of versions, too; here's the result for it:

--- Ranking (HTTP/2 only, median times) ---
  🥇 1. undici (request): 19.30ms ±4.32ms (baseline)
  🥈 2. undici (request + abortSignal): 20.71ms ±4.48ms (+7.35%)
  🥉 3. undici (minimal): 37.63ms ±6.80ms (+95.02%)
  🥉 4. axios: 41.59ms ±5.76ms (+115.56%)
  🥉 5. undici (fetch): 45.39ms ±6.39ms (+135.21%)

--- Ranking (HTTP/1.1 only, median times) ---
  🥇 1. axios: 141.10ms ±58.88ms (baseline)
  🥈 2. undici (fetch): 499.29ms ±255.66ms (+253.85%)

Regarding h1, I'll implement your suggestion of using an explicit agent for undici. This will likely solve the performance problem we can see in this test and will generate good insights on how to use fetch at our company.

[Farenheith]

I've run tests again after creating a persistent agent for h1 undici, and the results shifted:

-- Ranking (HTTP/2 only, median times) ---
  🥇 1. undici (request): 21.18ms ±3.51ms (baseline)
  🥈 2. undici (request + abortSignal): 21.83ms ±3.00ms (+3.04%)
  🥉 3. axios: 36.99ms ±6.78ms (+74.63%)
  🥉 4. undici (minimal): 37.57ms ±5.24ms (+77.35%)
  🥉 5. undici (fetch): 42.91ms ±7.05ms (+102.57%)

--- Ranking (HTTP/1.1 only, median times) ---
  🥇 1. undici (fetch): 55.96ms ±7.63ms (baseline)
  🥈 2. axios: 127.19ms ±62.56ms (+127.29%)

Now Undici beats axios in h1 by a fair margin. Maybe a valid improvement for Undici is to have an internal, persistent agent when no agent is specified. Still, this is easily manageable by the caller.

Thanks again for your tips! I'll adjust our usage now based on that!