Optimizing Front-End Build Performance with Rspack in UmiJS Projects

This article describes a practical case of improving build speed for large-scale front‑end applications that originally use Webpack. The growing codebase and dependency count caused compilation time to occupy about 50% of the overall build duration, severely affecting developer productivity.

Two mainstream optimization directions are examined: (1) caching or pre‑building techniques implemented in Node.js, which have limited applicability in cold‑start scenarios; (2) re‑implementing the compilation pipeline in high‑performance languages such as Go or Rust. The latter includes tools like esbuild and SWC, which have demonstrated significant speed gains.

After evaluating industry solutions—Rspack, Vite, Turbopack, and swc‑pack—the team selected Rspack because it offers Rust‑based core performance while maintaining high compatibility with the existing Webpack ecosystem, thus minimizing migration cost.

The target applications are built with React + UmiJS (mostly UmiJS@4) and Webpack. By introducing a custom Rspack command via an UmiJS plugin, the project can switch to Rspack with only minor configuration changes and no business‑code modifications.

Key challenges addressed:

UmiJS only supports Webpack and Vite; extending it to Rspack required creating new dev/build commands.

Many UmiJS and Babel plugins rely on Webpack‑specific configuration; the solution maps these configurations to Rspack equivalents.

Ensuring ultra‑low integration cost so that developers only need to install a plugin and adjust the npm scripts.

The implementation involves:

Adding @umijs/plugin-rspack as a dependency.

Registering the plugin in config/config.ts :

{
  // other config
  plugins: [
    // other plugins
    '@umijs/plugin-rspack',
  ],
  // other config
}

Updating the build scripts to use rspack-dev and rspack-build instead of the default max dev / max build :

{
  "scripts": {
    "start": "cross-env BUILD_ENV=dev NODE_ENV=development max rspack-dev",
    "pnpm:build:t1": "cross-env BUILD_ENV=t1 NODE_ENV=production max rspack-build"
  }
}

Technical highlights include:

Support for TS/TSX via the built‑in builtin:swc-loader with appropriate jsc.parser options.

React Fast Refresh using @rspack/plugin-react-refresh and enabling devServer.hot :

import ReactRefreshPlugin from '@rspack/plugin-react-refresh';
export default {
  devServer: { hot: true },
  plugins: [isDev && new ReactRefreshPlugin()],
};

Module Federation is available in two versions; for compatibility with existing Webpack MF setups, the article recommends using container.ModuleFederationPluginV1 :

import { container } from '@rspack/core';
export default {
  plugins: [new container.ModuleFederationPluginV1({ /* MF config */ })],
};

For on‑demand style imports, babel-plugin-import is replaced by the SWC experimental import option, enabling automatic Ant Design or Poizon‑Design style injection.

CSS‑Modules are handled by auto-css-modules logic, which can be replicated in Rspack using swc-plugin-auto-css-modules and the type: 'css/module' rule.

Performance‑impacting devtool settings are discussed; source-map adds roughly 30% overhead, while eval or disabling devtool yields the fastest builds. The article provides benchmark screenshots for different devtool configurations.

Additional low‑efficiency patterns are identified, such as importing full antd.less files, which can add 4‑7 seconds per import. Removing these imports yields noticeable build‑time reductions.

The migration resulted in an average 2×+ compilation speed improvement across 17 applications, with a concrete example dropping from 150 s to 40 s (≈73% reduction) and further to ~20 s after code cleanup.

Future work includes extending support for remaining Babel plugins, updating to newer Rspack versions that have upgraded swc_core , and broader rollout beyond development and testing environments.