nock vs msw: Should You Switch? 2.9ms vs 0.5ms

I mocked the same 2,000 sequential fetch calls in Node 20 with nock 14.0.17 and msw 2.15.0: nock took a median 2.85 ms per request, msw took 0.49 ms (about 5.8x faster). Through axios, which goes through Node's http module instead of fetch, the gap shrank to 3.80 ms versus 1.41 ms per request (about 2.7x).

Short answer: switch to msw if your Node tests mock hundreds of fetch calls, or if you want the same handlers in the browser. Stay on nock if your suite is small, leans on nock-only features like scope.done() and recorder mode, and runs fast enough today. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM Linux cloud box, Node 20.19.2, tested 5 Oct 2026 (about 23:38 to 23:43 IST). Shared box; each run in a fresh Node process, one warmup per variant, then seven interleaved rounds.
• Fixture: /workspace/bench-msw-nock/run.mjs. One mocked endpoint GET https://api.example.test/users/:id returning a small JSON object. After one check request, the script awaits 2,000 requests in a row and checks each response id. All 2,000 came back correct in every run.
• Tools: msw 2.15.0 (setupServer, onUnhandledRequest: 'error'), nock 14.0.17 (persist(), regex path, disableNetConnect()), axios 1.20.0. Baseline: a real node:http server on 127.0.0.1 with no mocking library.
• Timing: performance.now() around the 2,000-request loop, plus a separate number for import + setup + first request, plus the full process wall clock.
• Findings: loop medians were msw fetch 987 ms, nock fetch 5,710 ms, real loopback fetch 955 ms; msw axios 2,813 ms, nock axios 7,594 ms, real loopback axios 1,031 ms. Setup plus first request: nock 97 ms, msw 208 ms (fetch).
• One surprise: both libraries depend on @mswjs/interceptors 0.41, yet nock was still 5.8x slower on fetch. A static reply object instead of a reply function did not change it (5.67 to 5.73 s across three runs).
• Not tested: msw 3.x (3.0.2 needs Node 22.12 or newer, so it would not run here), browser or service worker mode, Vitest or Jest wiring, concurrent requests, GraphQL handlers, nock recorder, Windows/macOS.

Is msw faster than nock?

Variant	Median per request	Loop for 2,000	Setup + first request
msw 2.15 + fetch	0.49 ms	987 ms	208 ms
nock 14 + fetch	2.85 ms	5,710 ms	97 ms
msw 2.15 + axios	1.41 ms	2,813 ms	306 ms
nock 14 + axios	3.80 ms	7,594 ms	187 ms
real loopback server + fetch	0.48 ms	955 ms	80 ms
real loopback server + axios	0.52 ms	1,031 ms	165 ms

On this fixture, yes, per request. msw on fetch was about as fast as hitting a real server on loopback. nock loads faster, so a process that makes only ten requests finishes first under nock: about 126 ms (97 + 29) versus 213 ms (208 + 5). The crossover in my numbers is around 50 requests per process. A suite that mocks 500 fetch calls would spend about 1.4 s in nock versus 0.25 s in msw.

If you are also choosing the test runner, see the Jest vs Vitest post and the jsdom vs happy-dom for Vitest post.

Why is axios slower under both?

Axios in Node uses the http module, not fetch. Both libraries intercept that path by patching http.ClientRequest, and that layer cost more than fetch interception in my runs: msw went from 0.49 to 1.41 ms per request, nock from 2.85 to 3.80 ms. Without mocking, axios over loopback was 0.52 ms, so most of that extra time came from interception, not from axios. If your code calls an http-based client, expect a smaller gap between the two libraries than the fetch numbers suggest.

Should you switch from nock to msw?

Situation	My pick
Node tests with hundreds of mocked fetch calls	msw
Same request mocks wanted in browser dev and in tests	msw
Small suite, under about 50 mocked requests per test file	Stay on nock; the gap is noise
You rely on scope.done() assertions or nock's recorder	Stay on nock, or plan to rebuild those checks
Already on Node 22.12+ and starting fresh	msw 3.x is an option, but I did not test it here

Bottom line: 2,000 fetch calls took 0.99 s with msw and 5.71 s with nock on the same box. Who should not switch yet: teams with a large nock suite built on persist() chains and isDone() checks, where rewriting every mock costs more than the seconds you would save. For related test-speed choices, see the Vitest 5 upgrade post and the c8 vs nyc coverage post; for running TypeScript tests directly, the tsx vs ts-node post.

How this was made: I wrote the fixture, installed both libraries on the ShopperCove test box, timed interleaved runs in fresh processes and kept the JSON; the write-up was drafted with AI help and checked against that output.

Sources

• https://mswjs.io/docs/
• https://www.npmjs.com/package/msw
• https://github.com/mswjs/msw
• https://github.com/nock/nock
• https://www.npmjs.com/package/nock
• https://github.com/mswjs/interceptors

Related

• https://www.shoppercove.com/blog/jest-vs-vitest
• https://www.shoppercove.com/blog/jsdom-vs-happy-dom-vitest
• https://www.shoppercove.com/blog/vitest-5-should-you-upgrade-october-2026
• https://www.shoppercove.com/blog/c8-vs-nyc
• https://www.shoppercove.com/blog/tsx-vs-ts-node
• https://www.shoppercove.com/blog/playwright-1-63-test-locks-october-2026
• https://www.shoppercove.com/blog/nodejs-26-lts-october-2026-schedule-change
• https://www.shoppercove.com/blog/pnpm-vs-npm-vs-bun