# Source: https://rspack.dev/guide/optimization/profile.md

# Build performance profile

This chapter introduces some common performance bottlenecks and performance profile methods for Rspack.

## Analysis with Rsdoctor

[Rsdoctor](https://rsdoctor.rs/) is a build analyzer that can visually display the build process, such as compilation time, code changes before and after compilation, module reference relationships, duplicate modules, etc.

Please refer to [Use Rsdoctor](/guide/optimization/use-rsdoctor.md) for more information.

## Rspack profile

The Rspack CLI supports the use of the `RSPACK_PROFILE` environment variable for build performance profile.

```sh
RSPACK_PROFILE=ALL rspack build
```

This command will generate a `.rspack-profile-${timestamp}-${pid}` folder, and it will contain the `trace.json` file, which is generated by Rspack based on [tracing](https://github.com/tokio-rs/tracing) and can be viewed using [ui.perfetto.dev](https://ui.perfetto.dev/).

> See [Tracing](/contribute/development/tracing.md) for more information.

## Performance bottlenecks

Although Rspack itself provides good build performance, the use of some JavaScript loaders and plugins in Rspack can slow down the build performance, especially on large projects.

Some of these issues can be resolved with Rspack's built-in high performance alternatives, while others can be identified and optimized using performance analysis tools.

Here are some common cases:

### babel-loader

[babel-loader](https://github.com/babel/babel-loader) compiles JavaScript and TypeScript code using Babel. You can replace Babel with the faster SWC. Rspack comes with a built-in [builtin:swc-loader](/guide/features/builtin-swc-loader.md), which is the Rust version of `swc-loader` and is intended to provide better performance.

If you need to use some Babel plugins for custom transformations, configure babel-loader with [rules\[\].include](/config/module-rules.md#rulesinclude) to match as few files as possible to reduce the Babel compilation overhead.

### postcss-loader

[postcss-loader](https://github.com/postcss/postcss-loader) compiles CSS code based on PostCSS, which is often used with PostCSS plugins to downgrade CSS syntax, add vendor prefixes, etc. You can replace PostCSS with the faster Lightning CSS by using Rspack's built-in [builtin:lightningcss-loader](/guide/features/builtin-lightningcss-loader.md).

### terser-webpack-plugin

[terser-webpack-plugin](https://github.com/webpack/terser-webpack-plugin) minifies JavaScript code based on Terser. You can replace Terser with the faster SWC minimizer by using Rspack's built-in [SwcJsMinimizerRspackPlugin](/plugins/rspack/swc-js-minimizer-rspack-plugin.md).

### css-minimizer-webpack-plugin

[css-minimizer-webpack-plugin](https://github.com/webpack/css-minimizer-webpack-plugin) minifies CSS code based on tools like cssnano. You can replace cssnano with the faster Lightning CSS minimizer by using Rspack's built-in [LightningCssMinimizerRspackPlugin](/plugins/rspack/lightning-css-minimizer-rspack-plugin.md).

### less-loader

[less-loader](https://github.com/webpack/less-loader) compiles `.less` files based on Less. Since Less currently lacks an officially implemented high performance alternative, it is recommended to use [sass-loader](https://github.com/webpack/sass-loader) and [sass-embedded](https://www.npmjs.com/package/sass-embedded) instead. `sass-embedded` is a JavaScript wrapper for Sass's native Dart executable that provides excellent performance.

### html-webpack-plugin

[html-webpack-plugin](https://github.com/jantimon/html-webpack-plugin) performs poorly when generating large numbers of HTML files. The [HtmlRspackPlugin](/plugins/rspack/html-rspack-plugin.md) implemented in Rust by Rspack can provide better performance.

## Blocking thread pool size

Rspack internally uses a dedicated thread pool to handle blocking operations such as file system reads and writes, preventing the main thread from being blocked.

By default, the pool size is set to `4`, matching Node.js's [libuv](https://docs.libuv.org/en/v1.x/threadpool.html) behavior, which provides stable performance across most development and CI environments.

If your build environment uses high-speed storage, you can adjust the thread count via the `RSPACK_BLOCKING_THREADS` environment variable to improve parallelism and potentially reduce build time, for example:

```bash
# Need to install cross-env package to set environment variables
cross-env RSPACK_BLOCKING_THREADS=8 rspack build
```

After setting the variable, observe the build time to find the most suitable configuration.

On slower or high-latency file systems, it's recommended to keep the default value or even lower it to avoid thread contention.

## Working thread pool size

Rspack internally uses a Tokio thread pool and Rayon thread pool to handle CPU bound tasks (Tokio for async tasks and Rayon for sync tasks). By default, Tokio and Rayon automatically determines the number of worker threads based on the number of CPU cores available.

If it consumes too much CPU resources during the build process, you can limit the number of worker threads by setting the `TOKIO_WORKER_THREADS` and `RAYON_NUM_THREADS` environment variable, for example:

```bash
# Need to install cross-env package to set environment variables
cross-env TOKIO_WORKER_THREADS=4 RAYON_NUM_THREADS=4 rspack build
```

Be aware that setting this value too low may lead to longer build times. After setting the variable, observe the build time to find the most suitable configuration.