Rspack vs Webpack 5: Rust-Powered Bundling Speed in 2026

JavaScript bundlers sit at the heart of every modern frontend workflow. For nearly a decade, webpack reigned supreme — configurable, extensible, and battle-hardened across millions of projects. Then came Vite, esbuild, and Turbopack, each chipping away at webpack’s dominance with faster cold starts and leaner configs. In 2026, one bundler has quietly become the most compelling drop-in replacement webpack has ever faced: Rspack.

If you have a large webpack project and want 5–10x faster builds without a full rewrite, Rspack deserves your attention.

What Is Rspack?

Rspack is an open-source, high-performance JavaScript bundler built in Rust and developed by the infrastructure team at ByteDance. It was open-sourced in March 2023 and has since matured into a production-grade tool used inside TikTok, Douyin, and dozens of other high-traffic applications.

The core design goal is unambiguous: be API-compatible with webpack 5 while delivering dramatically faster build times by leveraging Rust’s concurrency model and low-level performance characteristics. Unlike Vite, which abandons the webpack mental model entirely in favor of native ES modules and a Rollup-based production build, Rspack stays firmly in the webpack paradigm — same config structure, same module resolution, same plugin hooks, same asset pipeline.

This compatibility-first approach is deliberate. ByteDance had thousands of internal applications running on webpack. Rewriting them all to use a new bundler was not realistic. Rspack had to work with existing webpack config files, existing loaders, and existing plugins from day one.

Key architectural decisions

Rspack implements webpack’s core algorithms — module graph construction, chunk splitting, tree shaking, code splitting — in Rust, using multi-threading to parallelize work that webpack performs serially in JavaScript. The JavaScript interop layer is handled through napi-rs, which allows Rust code to call into Node.js and vice versa with minimal overhead.

The result is a bundler that speaks webpack’s language but runs at a fundamentally different speed.

Performance Benchmarks in 2026

The performance gap between Rspack and webpack 5 is wide and consistent across project sizes.

Cold build times

On a representative React application with 5,000 modules:

• Webpack 5: ~28 seconds
• Rspack: ~4.2 seconds

On a large enterprise monorepo entrypoint with 20,000+ modules:

• Webpack 5: ~110 seconds
• Rspack: ~14 seconds

These are real-world figures from community benchmarks and internal reports published by ByteDance. The speedup consistently lands in the 5–10x range, with larger projects seeing the higher end of that improvement because Rspack’s parallelism scales with module count in a way that webpack’s single-threaded JavaScript runtime cannot.

Hot Module Replacement (HMR)

HMR latency is where developer experience lives day to day. Webpack HMR on a medium-sized project typically takes 800ms to 2 seconds to propagate a change. Rspack HMR routinely delivers under 100ms, often under 50ms on projects below 10,000 modules.

The difference is noticeable instantly. Editing a component and seeing the browser update in under 100ms feels qualitatively different from waiting 1–2 seconds.

Production builds with minification

Rspack uses SWC as its built-in minifier rather than Terser. SWC is itself Rust-based and significantly faster than Terser. A production build that takes 45 seconds with webpack 5 and Terser typically takes 6–8 seconds with Rspack.

Memory usage

Rspack uses less peak memory than webpack on large builds. On a 20,000-module project, webpack 5 can peak above 4GB of heap usage. Rspack typically stays below 1.5GB for the same input. This matters for CI environments with memory limits.

Webpack Plugin and Loader Compatibility

This is where Rspack’s story gets nuanced. The goal is webpack compatibility, but the implementation is not yet 100% complete.

What works

The vast majority of commonly used webpack loaders work with Rspack out of the box:

• babel-loader
• css-loader
• style-loader
• sass-loader
• less-loader
• postcss-loader
• file-loader and url-loader
• ts-loader (though builtin:swc-loader is faster)
• html-webpack-plugin (via @rspack/plugin-html or direct compatibility)
• mini-css-extract-plugin
• copy-webpack-plugin
• webpack-bundle-analyzer

Most plugins that hook into webpack’s compiler and compilation APIs work correctly because Rspack implements those APIs in its JavaScript interop layer.

What does not work or has caveats

Plugins that rely on webpack internals not exposed through the public API may fail silently or throw errors. Specifically:

• Plugins that directly access compilation.modules internals (not the public iteration API) may break.
• Some webpack 4-era plugins that were never updated for webpack 5 are also incompatible with Rspack.
• thread-loader is unnecessary and should be removed — Rspack handles parallelism internally.
• speed-measure-webpack-plugin has known issues and is not recommended with Rspack.
• Custom plugins using undocumented internal hooks may require minor patches.

The Rspack team maintains a compatibility table at rspack.dev. As of early 2026, compatibility with the webpack 5 plugin ecosystem is above 90% for production-grade plugins.

rspack.config.js Examples

One of Rspack’s strongest selling points is how familiar the configuration looks.

Basic configuration

// rspack.config.js
const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "[name].[contenthash].js",
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx|ts|tsx)$/,
        use: "builtin:swc-loader",
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: ["style-loader", "css-loader", "postcss-loader"],
      },
      {
        test: /\.(png|svg|jpg|jpeg|gif)$/i,
        type: "asset/resource",
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html",
    }),
  ],
  resolve: {
    extensions: [".js", ".jsx", ".ts", ".tsx"],
  },
};

Compare this to an equivalent webpack.config.js — the files are nearly identical. The main difference is builtin:swc-loader replacing babel-loader, which is faster and requires no separate Babel config for standard TypeScript and JSX transforms.

Production configuration with code splitting

// rspack.config.js
const path = require("path");
const { rspack } = require("@rspack/core");

module.exports = (env, argv) => {
  const isProd = argv.mode === "production";

  return {
    entry: {
      main: "./src/index.tsx",
    },
    output: {
      path: path.resolve(__dirname, "dist"),
      filename: isProd ? "[name].[contenthash:8].js" : "[name].js",
      publicPath: "/",
      clean: true,
    },
    optimization: {
      splitChunks: {
        chunks: "all",
        cacheGroups: {
          vendor: {
            test: /[\\/]node_modules[\\/]/,
            name: "vendors",
            chunks: "all",
          },
        },
      },
      runtimeChunk: "single",
    },
    module: {
      rules: [
        {
          test: /\.(tsx?|jsx?)$/,
          use: {
            loader: "builtin:swc-loader",
            options: {
              jsc: {
                parser: {
                  syntax: "typescript",
                  tsx: true,
                },
                transform: {
                  react: {
                    runtime: "automatic",
                  },
                },
              },
            },
          },
        },
        {
          test: /\.module\.css$/,
          use: ["style-loader", "css-loader"],
        },
        {
          test: /\.css$/,
          exclude: /\.module\.css$/,
          use: ["style-loader", "css-loader", "postcss-loader"],
        },
      ],
    },
    plugins: [
      new rspack.HtmlRspackPlugin({
        template: "./public/index.html",
      }),
      isProd &&
        new rspack.CopyRspackPlugin({
          patterns: [{ from: "public", to: ".", globOptions: { ignore: ["**/index.html"] } }],
        }),
    ].filter(Boolean),
    devServer: {
      historyApiFallback: true,
      port: 3000,
      hot: true,
    },
  };
};

Notice rspack.HtmlRspackPlugin — Rspack ships built-in versions of several common plugins implemented in Rust for maximum speed. You can use the JavaScript versions of these plugins, but the built-in Rust implementations are significantly faster.

Migration Guide: Webpack to Rspack

Migrating a standard webpack 5 project to Rspack typically takes under an hour for small to medium projects.

Step 1: Install Rspack

npm remove webpack webpack-cli webpack-dev-server
npm install -D @rspack/core @rspack/cli

If you use babel-loader only for TypeScript and JSX transforms, you can remove Babel dependencies entirely and switch to builtin:swc-loader.

Step 2: Rename your config file

Copy webpack.config.js to rspack.config.js. Rspack will automatically detect this filename.

Step 3: Update package.json scripts

{
  "scripts": {
    "dev": "rspack serve",
    "build": "rspack build",
    "preview": "rspack build --mode production"
  }
}

Step 4: Replace webpack-specific plugins with Rspack built-ins

Webpack plugin	Rspack built-in
html-webpack-plugin	rspack.HtmlRspackPlugin
copy-webpack-plugin	rspack.CopyRspackPlugin
mini-css-extract-plugin	rspack.CssExtractRspackPlugin
webpack.DefinePlugin	rspack.DefinePlugin
webpack.ProgressPlugin	rspack.ProgressPlugin

Using the built-in versions is optional but recommended for maximum performance.

Step 5: Replace babel-loader with builtin:swc-loader

// Before (webpack)
{
  test: /\.(js|jsx|ts|tsx)$/,
  use: {
    loader: "babel-loader",
    options: {
      presets: ["@babel/preset-env", "@babel/preset-react", "@babel/preset-typescript"],
    },
  },
}

// After (Rspack)
{
  test: /\.(js|jsx|ts|tsx)$/,
  use: {
    loader: "builtin:swc-loader",
    options: {
      jsc: {
        parser: { syntax: "typescript", tsx: true },
        transform: { react: { runtime: "automatic" } },
      },
    },
  },
}

Step 6: Test and fix

Run rspack build and check for errors. The most common issues are:

• Plugins accessing webpack internals directly — check the plugin’s GitHub for an Rspack-compatible version or a community fork.
• Missing @rspack/core peer dependency in plugins that detect their bundler via require('webpack').
• Custom loaders that use webpack-specific loader APIs (these are rare but exist in older codebases).

For most projects, the build will succeed on the first attempt or after fixing one or two plugin incompatibilities.

When to Use Rspack vs Staying with Webpack

Strong cases for migrating to Rspack

• Your webpack build takes more than 15 seconds cold. Rspack’s speedup is most valuable here.
• Your team frequently waits on HMR. Sub-100ms feedback changes development flow.
• You are on webpack 5 and have no exotic plugin dependencies.
• You run CI on every commit and build time directly affects pipeline duration and cost.
• You want to defer a full migration to Vite but still need faster builds today.

Cases where staying on webpack makes sense

• You depend on a plugin that is not yet compatible with Rspack and no alternative exists.
• Your build is already fast enough (under 10 seconds) and HMR is responsive.
• Your team is actively migrating to Vite and does not want an intermediate step.
• You use advanced webpack features like Module Federation v2 in configurations not yet fully supported by Rspack (check rspack.dev for the current compatibility status).

Rspack vs Vite vs Other Bundlers

The bundler landscape in 2026 has converged into a few clear choices depending on project type.

Vite remains the default for greenfield projects. Its dev server uses native ES modules without bundling, which makes startup near-instant. Production builds use Rollup. The tradeoff is that very large projects can have slow production builds, and migrating from webpack to Vite requires rethinking configuration and often updating plugin setups significantly.

Rspack is the best option for large existing webpack projects that cannot afford a full migration. It provides most of Vite’s HMR speed in development while keeping the webpack mental model intact and delivering fast production builds.

Turbopack (from Vercel) is deeply integrated into Next.js and is the default bundler for Next.js 15+. It is not a general-purpose bundler and is not the right choice outside the Next.js ecosystem.

esbuild is extremely fast but intentionally minimal. It lacks code splitting sophistication and CSS module support that production applications require. It is best used as a transformer inside other tools rather than as a standalone bundler.

Rollup remains the standard for library bundling. If you are publishing an npm package, Rollup produces the cleanest output.

The summary: use Vite for new projects, Rspack for migrating large webpack projects, Turbopack inside Next.js, and Rollup for libraries.

Production Readiness in 2026

Rspack reached its 1.0 stable release in late 2024 and has been running at ByteDance scale since its open-source launch in 2023. By early 2026, adoption has spread beyond ByteDance to a significant number of enterprise teams with large webpack codebases.

The project is actively maintained with frequent releases. Breaking changes between minor versions are rare. The documentation at rspack.dev covers migration, configuration, plugins, and the built-in loader API comprehensively.

Known production limitations to be aware of:

• Module Federation support exists but trails the webpack Module Federation v2 feature set in some advanced scenarios. Verify your specific use case before migrating federated architectures.
• Some less common webpack output formats (UMD with complex externals) have edge cases. Test production output carefully.
• Ecosystem tooling like Storybook and Jest transformers have Rspack support but may require specific version pins.

For standard React, Vue, or vanilla TypeScript SPAs with webpack 5, Rspack is unambiguously production-ready in 2026. The risk profile of migrating is low, and the performance payoff is immediate and substantial.

Conclusion

Rspack solves a real problem that no other tool addressed directly: how do you get Vite-class build performance without abandoning the webpack ecosystem that millions of production projects depend on? The answer is to rewrite webpack’s core in Rust while preserving its configuration API, plugin system, and module resolution behavior.

The 5–10x build speed improvement is not marketing — it is a structural consequence of Rust’s concurrency model applied to work that JavaScript executes serially. HMR under 100ms is similarly a direct result of architecture, not optimization tricks.

If your webpack build is slow and your migration to Vite feels risky or expensive, Rspack is the upgrade path you have been waiting for. Install @rspack/core, rename your config file, and run your first build. In most cases, that is all it takes.