Rspack vs Webpack: Speed Benchmarks 2026
Mews migrated their webpack monorepo to Rspack and cut startup time from 3 minutes to 10 seconds. ByteDance (Rspack's creator) reports 5-10x build improvements across internal projects. Rspack 1.0 benchmarks show 23x faster production builds than webpack 5 with Babel. These aren't demo projects — they're production systems with years of webpack history, and the drop-in replacement actually works.
TL;DR
Rspack is production-ready as of v1.0 (October 2024). For webpack-heavy projects (monorepos, enterprise apps, legacy codebases that can't migrate to Vite), Rspack is the highest-impact improvement you can make in 2026. Migration from webpack is 1-2 days for most projects. The webpack ecosystem compatibility is approximately 85%, covering the most commonly used loaders and plugins.
Key Takeaways
- Rspack 1.0 production builds: 23x faster than webpack 5 + Babel on equivalent benchmarks
- Real-world results: Mews -80% build time, ByteDance 5-10x, various teams 70%+ reductions
- 85%+ webpack plugin compatibility — most popular plugins work out of the box
- All webpack loaders (babel-loader, css-loader, ts-loader, file-loader) work unchanged
- Rspack uses webpack's configuration schema — minimal config changes needed
@rspack/coreis a drop-in forwebpack,rspack-cliis a drop-in forwebpack-cli- Used in production by ByteDance, Microsoft, Amazon, Discord, Shopify
What Is Rspack?
Rspack is a webpack-compatible JavaScript bundler written in Rust, built by the ByteDance (TikTok's parent company) frontend infrastructure team. It aims to be a drop-in replacement for webpack — same configuration format, same plugin/loader API, dramatically faster.
Unlike Vite or Farm (which require migrating your mental model), Rspack lets you keep your webpack configuration and just replace the binary.
Installation
# Remove webpack
npm uninstall webpack webpack-cli
# Install Rspack
npm install -D @rspack/core @rspack/cli
# Update package.json scripts
# Before:
"build": "webpack --config webpack.config.js",
"dev": "webpack serve --config webpack.config.js",
# After:
"build": "rspack build",
"dev": "rspack serve",
Configuration Compatibility
Your webpack config often works with minimal changes:
// webpack.config.js → rspack.config.js
// This is often the ONLY change needed:
- const webpack = require('webpack');
+ const rspack = require('@rspack/core');
module.exports = {
entry: './src/index.tsx',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js',
},
module: {
rules: [
{
test: /\.tsx?$/,
use: 'babel-loader', // Works unchanged
exclude: /node_modules/,
},
{
test: /\.css$/,
use: ['style-loader', 'css-loader', 'postcss-loader'], // Works unchanged
},
{
test: /\.(png|jpg|gif|svg)$/,
type: 'asset/resource', // webpack 5 asset modules work in Rspack
},
],
},
plugins: [
new rspack.HtmlRspackPlugin({ template: './src/index.html' }),
new rspack.DefinePlugin({ 'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV) }),
],
resolve: {
extensions: ['.ts', '.tsx', '.js', '.jsx'],
},
};
Built-in TypeScript and React Support
Rspack's biggest DX improvement over webpack: TypeScript and JSX/TSX compilation are built-in (via SWC), no Babel or ts-loader required:
// rspack.config.js — No babel-loader needed!
module.exports = {
entry: './src/index.tsx',
module: {
rules: [
{
test: /\.tsx?$/,
use: {
loader: 'builtin:swc-loader', // Built-in SWC, no install needed
options: {
jsc: {
parser: { syntax: 'typescript', tsx: true },
transform: { react: { runtime: 'automatic' } },
},
},
},
},
],
},
};
SWC is 20-70x faster than Babel for transpilation, which is a significant portion of webpack's build time.
Performance Benchmarks
Official Benchmark (1,000 React components)
| Bundler | Production Build |
|---|---|
| Rspack 1.0 | 282ms |
| Vite (Rollup) | 1,780ms |
| Turbopack | N/A (dev only) |
| webpack 5 + SWC | 832ms |
| webpack 5 + Babel | 6,523ms |
Real-World Migration Results
Mews (hospitality SaaS monorepo):
- Before: Cold start 3 minutes, production build 8+ minutes
- After: Cold start 10 seconds, production build 90 seconds
- Result: 80% build time reduction
ByteDance internal projects:
- 5-10x improvement across various projects
- Key factor: removing Babel entirely, using built-in SWC
Medium-sized React app (150K LOC, various teams):
- Before: 45-60 second dev startup, 8-minute production build
- After: 8-12 second dev startup, 90-second production build
- Result: ~70% improvement
Why Is Rspack Faster?
- Rust core: No JavaScript overhead for core bundling operations
- Parallelism: Multi-threaded by default (webpack is single-threaded JavaScript)
- Built-in SWC: Replaces Babel with a 20-70x faster transpiler
- Incremental compilation: Only rebuilds changed modules and their dependents
- Efficient algorithms: LLVM-optimized graph traversal and tree-shaking
Plugin Compatibility
Plugins That Work Out of the Box
| Plugin | Notes |
|---|---|
HtmlWebpackPlugin | Rspack has HtmlRspackPlugin (built-in, faster) |
MiniCssExtractPlugin | Use CssExtractRspackPlugin (built-in) |
DefinePlugin | Use rspack.DefinePlugin |
CopyPlugin | Supported |
BannerPlugin | Supported |
webpack-bundle-analyzer | Works with Rspack |
fork-ts-checker-webpack-plugin | Works |
eslint-webpack-plugin | Works |
Plugins That Need Alternatives
| webpack Plugin | Rspack Alternative |
|---|---|
HtmlWebpackPlugin | rspack.HtmlRspackPlugin (built-in) |
MiniCssExtractPlugin | rspack.CssExtractRspackPlugin (built-in) |
terser-webpack-plugin | Built-in (SWC minifier) |
speed-measure-webpack-plugin | Not needed (Rspack has built-in profiling) |
Loaders That Work
All webpack loaders that don't require webpack internals work unchanged:
# These all work:
babel-loader # Or replace with builtin:swc-loader
css-loader
style-loader
postcss-loader
sass-loader
less-loader
file-loader
url-loader
ts-loader # Or replace with builtin:swc-loader
vue-loader # Works (Rspack has Vue support)
Rsbuild: The High-Level Abstraction
ByteDance also released Rsbuild — a higher-level build tool on top of Rspack, similar to how Vite is a build tool on top of Rollup:
npm install -D @rsbuild/core
// rsbuild.config.ts
import { defineConfig } from '@rsbuild/core';
import { pluginReact } from '@rsbuild/plugin-react';
import { pluginSass } from '@rsbuild/plugin-sass';
export default defineConfig({
plugins: [pluginReact(), pluginSass()],
html: {
template: './src/index.html',
},
source: {
entry: { index: './src/index.tsx' },
},
output: {
distPath: { root: 'dist' },
},
});
Rsbuild provides zero-config defaults similar to Create React App or Vite's defaults, but with Rspack's performance.
Migration Guide
Step 1: Install Rspack
npm uninstall webpack webpack-cli html-webpack-plugin mini-css-extract-plugin terser-webpack-plugin
npm install -D @rspack/core @rspack/cli
Step 2: Rename Config
cp webpack.config.js rspack.config.js
Step 3: Update Imports
// rspack.config.js
// Replace:
const webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
// With:
const rspack = require('@rspack/core');
// HtmlRspackPlugin and CssExtractRspackPlugin are built-in
Step 4: Update Plugins
plugins: [
// Replace:
new HtmlWebpackPlugin({ template: './src/index.html' }),
new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }),
// With:
new rspack.HtmlRspackPlugin({ template: './src/index.html' }),
new rspack.CssExtractRspackPlugin({ filename: '[name].[contenthash].css' }),
],
Step 5: Switch to SWC Loader (Optional but Recommended)
// Replace babel-loader with built-in SWC:
{
test: /\.[jt]sx?$/,
use: {
loader: 'builtin:swc-loader',
options: {
jsc: {
parser: { syntax: 'typescript', tsx: true },
transform: { react: { runtime: 'automatic' } },
},
},
},
}
This step alone often yields another 30-50% build time reduction.
Step 6: Update package.json Scripts
{
"scripts": {
"dev": "rspack serve",
"build": "rspack build",
"build:analyze": "RSPACK_BUNDLE_ANALYZER=true rspack build"
}
}
When Rspack Makes Sense
Choose Rspack if:
- You have a large webpack codebase that can't realistically migrate to Vite
- Build times are noticeably impacting developer velocity
- You're in a monorepo with webpack at the core
- Your project relies on webpack-specific plugins that don't have Vite equivalents
- You want 80% of the migration effort at 50% of the migration risk
Migrate to Vite instead if:
- You're starting a new project
- Your webpack config is relatively simple
- You want the larger ecosystem (more plugins, better docs)
- Framework integration matters (SvelteKit, Astro, Nuxt use Vite)
Stick with webpack if:
- Your project is stable, builds are acceptable, and migration risk outweighs benefits
- You rely on webpack plugins with no Rspack equivalents
- You're in a regulated environment where change control is significant overhead
Ecosystem & Community
Rspack's community has grown dramatically since the 1.0 release in October 2024. ByteDance created and maintains it, and they have strong incentive to keep it stable — their own internal tooling depends on it. The Rspack GitHub repository has over 10,000 stars, and the Discord community is active with maintainers responding to issues within hours.
The Rsstack ecosystem is expanding: Rsbuild (zero-config build tool), Rslib (library bundler), and Rsdoctor (build analysis tool) form a coherent toolchain built on Rspack. This mirrors how Vite has Vitest, VitePress, and a plugin ecosystem. ByteDance is investing in making Rspack the center of a complete JavaScript build ecosystem.
One important community consideration: Rspack documentation is thorough but still maturing. Some webpack features have gaps in the Rspack docs that require reading webpack docs and extrapolating. This is improving rapidly, but teams migrating complex webpack configurations should expect some research time.
Real-World Adoption
Beyond the headline cases of Mews and ByteDance, Rspack adoption in 2026 extends across Microsoft (several internal tools), Amazon (e-commerce frontend tooling), and Discord (client build system). These are large-scale webpack codebases where Vite migration would require months of work, but Rspack provided substantial gains with days of effort.
Particularly notable is the adoption pattern: Rspack is almost always chosen by teams that cannot easily migrate to Vite. If your webpack config is 500 lines with custom loaders, module federation, and complex code splitting, Rspack is the pragmatic path. Teams that can use Vite generally still do — the Vite ecosystem is broader, and Vite's dev server story is excellent. But for legacy webpack projects at scale, Rspack has become the go-to answer.
Developer Experience Deep Dive
The development server experience in Rspack is noticeably better than webpack. Hot Module Replacement (HMR) is faster because Rspack's incremental compilation engine only recalculates the dependency graph for changed files, not the entire graph. On a large React application with 500+ components, HMR updates that took 3-5 seconds in webpack take under 500ms in Rspack.
TypeScript support deserves special mention. The built-in swc-loader replaces both ts-loader and babel-loader in one step. There's no separate compilation step — TypeScript is transformed at build time by SWC's native Rust implementation. The tradeoff is that type checking is not performed by Rspack itself; you still need tsc --noEmit or fork-ts-checker-webpack-plugin for type validation. This is a conscious design choice — faster builds at the cost of inline type checking.
Final Verdict 2026
Rspack 1.0 is a genuine production-ready webpack replacement in 2026. The compatibility story is better than expected — most webpack projects can migrate in 1-2 days with significant performance gains. The 80% build time reductions reported by multiple companies are real, not cherry-picked benchmarks.
If you have a webpack codebase and build speed is a pain point, Rspack is the lowest-risk, highest-reward optimization available. The configuration format is familiar, the loaders work, and the performance gains are immediate. For new projects, Vite remains the default choice — but for the millions of lines of production code running on webpack today, Rspack is the upgrade path.
The Risk Assessment
The question most teams ask before adopting Rspack is not whether it's faster — the benchmarks are convincing — but whether the migration is safe. The 85% plugin compatibility figure deserves some unpacking. The 15% incompatibility is concentrated in specialized use cases: custom webpack plugins that access webpack internals, Module Federation configurations in very large applications, and obscure loader combinations that use undocumented webpack behavior.
For the large majority of webpack users — those using standard loaders and the most common plugins — the compatibility rate is effectively higher than 85%. The teams that report rough migrations are typically those with highly customized webpack configurations built up over many years. If your webpack config is under 200 lines and uses standard plugins, the migration is almost certainly smooth.
The rollback story is also important. Rspack and webpack can coexist in the same codebase during migration — you can run rspack build for your main application while keeping webpack build for a legacy module federation configuration that isn't yet compatible. This gradual migration path reduces the risk of a big-bang switch that breaks production.
Rspack vs Turbopack
A natural comparison point is Turbopack — Vercel's Rust-based bundler designed as the successor to webpack for Next.js. Turbopack is faster than Rspack in some benchmarks (particularly the Next.js dev server scenario), but it's not yet production-ready for arbitrary webpack codebases. Turbopack is deeply integrated with Next.js and designed as a Next.js-specific solution, not a general webpack replacement.
Rspack occupies a different niche: it's a general-purpose webpack replacement that works with any webpack configuration, not just Next.js. If you're running Next.js, Turbopack is the roadmap target, but it requires waiting for Next.js team support. If you're running a custom webpack configuration, Rspack is available today with clear migration documentation.
Ecosystem Trajectory
Rspack's npm download numbers are growing month over month. The trajectory from ByteDance's internal tool to a production-ready open source bundler with adoption at Microsoft, Amazon, and Discord represents a validation that the compatibility-first approach works. The Rsbuild ecosystem (zero-config build tool), Rslib (library bundler), and Rsdoctor (bundle analyzer) suggest ByteDance is investing in making Rspack the center of a JavaScript build ecosystem rather than a one-off tool.
The question for 2027 and beyond is whether Rspack maintains its compatibility advantage as webpack continues to evolve. The Rspack team has committed to tracking webpack's API surface, which requires ongoing effort as webpack adds new features. This is a maintenance challenge that the Rspack team is aware of and actively managing, but it's worth noting as a long-term sustainability consideration.
Compare rspack vs webpack download trends on PkgPulse.
Compare Rspack and Webpack package health on PkgPulse.
For broader build tooling context, see best monorepo tools 2026. If you're making decisions about your JavaScript toolchain more broadly, best JavaScript package managers 2026 covers the dependency management side of the equation. For the bundler ecosystem more broadly — Vite, Turbopack, and Rolldown — see the farm vs Vite vs Turbopack next-gen bundlers comparison.