Apply loaders to the minimal number of modules necessary.
// instead of... module.exports = { //... module: { rules: [ { test: /\.js$/, loader: 'babel-loader' } ] } }; // try using the include target module.exports = { //... module: { rules: [ { test: /\.js$/, include: path.resolve(__dirname, 'src'), loader: 'babel-loader' } ] } };
Each additional loader/plugin has a bootup time. Try to use as few tools as possible.
The following can increase resolving speed:
resolve.modules
, resolve.extensions
, resolve.mainFiles
, resolve.descriptionFiles
, as they increase the number of filesystem calls.resolve.symlinks: false
if you don't use symlinks (eg npm link
or yarn link
).resolve.cacheWithContext: false
if you use custom resolving plugins, that are not context specific.Use the DllPlugin
to move code that is changes less frequently into a separate compilation. This will improve app compilation speed, although it does increase complexity of the build process.
Decrease the total size of the compilation to increase build performance. Try to keep chunks small.
SplitChunksPlugin
in Multi-Page ApplicationsSplitChunksPlugin
in async
mode in Multi-Page ApplicationsThe thread-loader
can be used to offload expensive loaders to a worker pool.
Don't use too many loaders. There is a boot overhead for the Node.js runtime and the loader. Minimize the module transfers between worker and main process. IPC is expensive.
Enable persistent caching with the cache-loader
. Clear cache directory on "postinstall" in package.json
.
Profile them to not introduce a performance problem here.
Use watch mode. Specifically Webpack's.
If CPU overloads due to poling mode, you can increase the polling interval with watchOptions.poll
.
Following utils improve performance by compilin and serving assets in memory rather than writing to disk:
webpack-dev-server
webpack-hot-middleware
webpack-dev-middleware
Be aware of the performance differences between the different devtool settings.
cheap-source-map
variants are more performant if you can live with the slightly worse mapping quality.eval-source-map
variant for incremental builds.
=> In most cases, cheap-module-eval-source-map
is the best option.[TO FINISH => up to https://webpack.js.org/guides/build-performance/#minimal-entry-chunk]