A great chunk splitting strategy is very important to improve the loading performance of the application. It can make full use of the browser's caching mechanism to reduce the number of requests and improve the loading speed of the application.
Several chunk splitting strategies are built into Rsbuild. These should meet the needs of most applications. You can also customize the chunk splitting config to suit your own usage scenario.
The chunk splitting config of Rsbuild is in performance.chunkSplit.
Rsbuild supports the following chunk splitting strategies:
split-by-experience
: an empirical splitting strategy, automatically splits some commonly used npm packages into chunks of moderate size.split-by-module
: split by NPM package granularity, each NPM package corresponds to a chunk.split-by-size
: automatically split according to module size.all-in-one
: bundle all codes into one chunk.single-vendor
: bundle all NPM packages into a single chunk.custom
: custom chunk splitting strategy.Rsbuild adopts the split-by-experience
strategy by default, which is a strategy we have developed from experience. Specifically, when the following npm packages are referenced in your project, they will automatically be split into separate chunks:
lib-polyfill.js
: includes core-js
, @babel/runtime
, @swc/helpers
, tslib
.lib-react.js
: includes react
, react-dom
, scheduler
.lib-router.js
: includes react-router
, react-router-dom
, history
, @remix-run/router
.lib-lodash.js
: includes lodash
, lodash-es
.lib-axios.js
: includes axios
and related packages.This strategy groups commonly used packages and then splits them into separate chunks. Generally, the number of chunks is not large, which is suitable for most applications and is also our recommended strategy.
Split each NPM package into a Chunk.
This strategy will split the node_modules in the most granular way, and at the same time, under HTTP/2, multiplexing will speed up the loading time of resources.However, in non-HTTP/2 environments, it needs to be used with caution because of HTTP head-of-line blocking problem.
This strategy puts all source code and third-party dependencies in the same Chunk.
If you need to bundle the chunks split by dynamic import into the single file, you can set the output.asyncChunks option in Rspack to false
:
This strategy puts third-party dependencies in one Chunk, and source code in another chunk.
Under this strategy, after setting minSize
, maxSize
to a fixed value, Rsbuild will automatically split them without extra config.
In addition to using the built-in strategies, you can also customize the splitting strategy to meet more customization needs. Custom strategy is divided into two parts:
splitChunks
configIt is worth noting that these two custom capabilities can be used together with the built-in strategy, that is, you can use the built-in strategy to split commonly used packages, and then use the custom function to split other packages.
Rsbuild supports custom group, which is more flexible than the built-in strategies, and simpler than writing bundler config.
For example, split the axios
library under node_modules into axios.js
:
Through forceSplitting
config, you can easily split some packages into a Chunk.
Chunks split using the forceSplitting
configuration will be inserted into the HTML file as resources requested for the initial screen using <script>
tags. Therefore, please split them appropriately based on the actual scenario to avoid excessive size of initial screen resources.
In addition to using custom grouping, you can also customize the native bundler config through override
, such as:
The config in override
will be merged with the bundler config. For specific config details, please refer to Rspack - splitChunks.
In addition to the chunkSplit
configurations, using dynamic import for code splitting is also an important optimization technique that can effectively reduce the initial bundle size.
Dynamic import is a new feature introduced in ECMAScript 2020 that allows you to dynamically load JavaScript modules. The underlying Rspack used by the Rsbuild supports dynamic import by default, so you can use it directly in your code.
When the bundler encounters the import()
syntax, it automatically splits the relevant code into a new chunk and loads it on-demand at runtime.
For example, if your project has a large module called bigModule.ts
(which can also be a third-party dependency), you can use dynamic import to load it on-demand:
When you run the build command, bigModule.ts
will be automatically split into a new chunk and loaded on-demand at runtime.