Rspack vs Webpack: Which Builds Faster? 0.54s vs 4.3s

On a 201-module React app I generated for this test, Webpack 5.111.1 with Babel 7 took a median 4.33 s for a cold production build, and Rspack 2.2.8 with builtin:swc-loader took 0.54 s on the same machine. That is about 8x.

Short answer: migrate if you already live in a Webpack config and production builds are eating CI or deploy time. Stay on Webpack, or pick Vite for a greenfield app, if you depend on a plugin Rspack does not support yet. 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 22:40 to 22:50 IST). Shared box; tools interleaved each round.
• Fixture: 200 small React function components plus one entry that imports all of them (201 modules). React 18.3.1 + react-dom. JSX, no CSS, no code splitting.
• Webpack: 5.111.1 + webpack-cli 5.1.4, babel-loader 9.2.1, @babel/core 7.28.4, @babel/preset-env + @babel/preset-react, mode: production, minify on, cacheDirectory off.
• Rspack: @rspack/core 2.2.8 + @rspack/cli 2.2.8, builtin:swc-loader with ecmascript+jsx, mode: production, minify on. Config shape mirrors the Webpack one on purpose.
• Timing: five interleaved cold production builds each (output dirs deleted every run). Median wall-clock for the whole CLI command.
• One surprise: raw bundle.js was 174 KB under Webpack and 365 KB under Rspack, but gzip was close (about 48 KB vs 52 KB). Size comparisons without gzip would have lied.
• Not tested: HMR / dev server, Module Federation, custom Webpack plugins, CSS pipelines, source maps, Windows/macOS, a real app migration.

Is Rspack faster than Webpack?

Bundler	Transpile	Median cold prod build	Runs
Webpack 5.111.1	Babel 7 (babel-loader)	4.33 s	3.84 / 6.05 / 4.33 / 3.97 / 4.39
Rspack 2.2.8	builtin:swc-loader	0.54 s	0.61 / 0.59 / 0.53 / 0.51 / 0.54

Rspack was about 8.0x faster at the median. Webpack had one slow outlier at 6.05 s; Rspack stayed inside 0.51–0.61 s. This is the common migration pairing (Babel Webpack to SWC Rspack), not an identical-transformer A/B. If your Webpack build already uses swc-loader, expect a smaller gap than these numbers.

Bundle size on this fixture:

Output	Raw	Gzip
Webpack dist-wp/bundle.js	174,380 bytes	~47.9 KB
Rspack dist-rspack/bundle.js	365,234 bytes	~51.9 KB

Raw size roughly doubled under Rspack's minifier here; after gzip the difference was about 8%. Ship and CDN bills care about gzip (or Brotli), so I would not block a migrate on the raw number alone, but I would check your real entry's compressed size before calling the migrate done. The Rspack 2.2.8 notes cover resolver cache and memory work in that release; the Webpack 5.111 ESM output notes are the matching Webpack baseline on this site.

What breaks when you migrate?

Rspack aims at Webpack 5-compatible config. On this fixture the swap was: change the package, point the CLI at the same entry/output shape, and replace babel-loader with builtin:swc-loader. Node must meet Rspack 2's engine range (^20.19.0 || >=22.12.0); this box was on 20.19.2.

Real projects fail on plugins and loaders Webpack has and Rspack does not, or on SWC Wasm plugins built for an older swc_core (Rspack 2.2 bumped to 77). Read the unsupported list in the official migrate guide before you delete Webpack from CI. Also re-check compressed bundle size and a smoke test of the production assets; raw size alone is a noisy signal.

If you are not on Webpack today, this is the wrong comparison. A Vite-first app should measure Vite, not force a Rspack hop. The Vite 8.3.2 post is the closer next step for that stack.

Should you switch from Webpack to Rspack?

Situation	My pick
Webpack 5 app, Babel loader, slow prod CI builds, ordinary loaders	Try Rspack; keep the config shape and swap the loader
Already on swc-loader under Webpack	Still try Rspack, but re-benchmark; do not expect a full 8x
Depends on a Webpack-only plugin with no Rspack port	Stay, or isolate that package
Greenfield SPA with no Webpack history	Prefer Vite unless you need Webpack's plugin surface
Only local rebuilds feel slow	Profile HMR/dev first; this post measured cold prod only

Bottom line: on 201 modules, Rspack 2.2.8 cut a 4.3 s Webpack+Babel production build to 0.54 s, with gzipped output nearly the same size. Who should not switch yet: teams blocked on an unsupported plugin, or teams that are not on Webpack at all. Everyone else with a painful Webpack prod build should measure their own app the same way before rewriting the pipeline.

How this was made: I generated the fixture, ran every build on the ShopperCove test box, and kept the timing JSON; the write-up was drafted with AI help and checked against that output.

Sources

• https://www.rspack.dev/guide/migration/webpack
• https://www.rspack.dev/blog/announcing-2-2
• https://webpack.js.org/guides/getting-started/
• https://www.npmjs.com/package/@rspack/core
• https://www.npmjs.com/package/webpack
• https://swc.rs/docs/usage/swc-loader

Related

• https://www.shoppercove.com/blog/rspack-2-2-8-resolver-cache-memory-october-2026
• https://www.shoppercove.com/blog/webpack-5-111-esm-output-stable-september-2026
• https://www.shoppercove.com/blog/vite-8-3-2-renderbuilturl-bundled-dev-sourcemaps-october-2026
• https://www.shoppercove.com/blog/vite-plus-1-0-unified-toolchain-october-2026
• https://www.shoppercove.com/blog/turborepo-2-11-7-sdkroot-oidc-cache-october-2026
• https://www.shoppercove.com/blog/pnpm-vs-npm-vs-bun
• https://www.shoppercove.com/blog/bun-1-4-2-elysia-als-cmyk-jpeg-october-2026
• https://www.shoppercove.com/blog/nodejs-26-lts-october-2026-schedule-change