Mastering Webpack SplitChunks Plugin: Tips and Tricks

Webpack is a powerful tool that enables developers to bundle and optimize their web applications.

The SplitChunks plugin, in particular, is an essential feature that helps break down large codebases into smaller chunks, improving overall performance and speed.

In this article, we’ll explore some tips and tricks that we’ve used to configure the SplitChunks plugin in Webpack and optimize our applications.

We upgraded configuration of Splitchunks plugin to reduce overall bundle size, the number of network requests to load our application and get benefit of long term caching.

SplitChunks Plugin and Chunks

A chunk is code which will break apart from main bundle that is main.js and form it’s own file known as chunk file.

There are two types of chunks viz. sync and async.

*1. *Sync chunks are loaded synchronously with main.js and you would see <script src="some-chunk.js"></script> element in source code.

2. Async chunks are loaded on demand (lazy loaded) and you would see network request for async chunk files in developers tool. These chunks are spitted from main.js based on some conditions and we need to tell that to the Webpack. This is done through Webpack plugin known as splitChunksPlugin.

Chunks Property: all, initial and async

all means both dynamically imported modules and statically imported modules will be selected for optimization.

initial means only statically imported modules will be selected for optimization.

async means only dynamically imported modules will be selected for optimization.

splitChunks: {
    {
     minSize: 17000,
     minRemainingSize: 0,
     minChunks: 1,
     maxAsyncRequests: 30,
     maxInitialRequests: 30,
     automaticNameDelimiter: "_",
     enforceSizeThreshold: 30000,
     cacheGroups: {
      common: {
       test: /[\\/]node_modules[\\/]/,
       priority: -5,
       reuseExistingChunk: true,
       chunks: "initial",
       name: "common_app",
       minSize: 0,
      },
      default: {
       minChunks: 2,
       priority: -20,
       reuseExistingChunk: true,
      },
      // we are opting out of defaultVendors, so rest of the node modules will be part of default cacheGroup
      defaultVendors: false,
      reactPackage: {
       test: /[\\/]node_modules[\\/](react|react-dom|react-router|react-router-dom)[\\/]/,
       name: 'vendor_react',
       chunks: "all",
       priority: 10,
      }
     },
    },
   },

Configuring Custom CacheGroups

We created a separate chunk for react and its related libraries so that we get the benefit of long term caching in browser as the versions of these libraries are rarely upgraded. ‘chunks’ property is set to ‘all’ so that even if they are statically imported or dynamically imported they are always part of this cacheGroup.

reactPackage: {
       test: /[\\/]node_modules[\\/](react|react-dom|react-router|react-router-dom)[\\/]/,
       name: 'vendor_react',
       chunks: "all",
       priority: 10,
      }

We created a separate chunk for all the node modules required initially in our react application so that they are not duplicated in other chunks.

Explicitly set minSize property to 0, so that even if the size of initial required node modules changes and becomes less than default specified value(17000 bytes, in our case) it still is a seperate chunk. ‘chunks’ property is set to ‘initial’ so that only statically imported modules will be selected for optimization.

common: {
       test: /[\\/]node_modules[\\/]/,
       priority: -5,
       reuseExistingChunk: true,
       chunks: "initial",
       name: "app_node_modules",
       minSize: 0,
      },

For default cacheGroup, we specified minChunks property to 2, which means that a module must be required in atleast two chunks, only then it will be part of this cacheGroup and minimum size of the chunks created from rules of this cacheGroup must be 17000 bytes.

The default minimum size of the chunks defined by webpack is 20000 bytes. The optimal size vary for different applications. By trying different values for minSize, we noted down total number of chunks and overall size of the app and for 17000 bytes we found both these parameters to be optimal.

Also we observed that some of our node modules were not behaving according to the default configuration specified, so explicitly specified false for defaultVendors cachegroup.

default: {
       minChunks: 2,
       priority: -20,
       reuseExistingChunk: true,
      },
      // we are opting out of defaultVendors, so rest of the node modules will be part of default cacheGroup
      defaultVendors: false,

Also, we lazy loaded some of our react components, which were of small size so we merged them into a single component to further reduce the number of network requests.

Using the above strategy, reduced GZipped bundle size ​and number of JS chunks(Network Requests) to load react app.​

Bonus Tips:

Explicity specify priority for each cacheGroup so that a module is not part of multiple cacheGroups at a time.

Default config for webpack defines two cacheGroups, one for node modules and other for remaining modules. You can see their config in wepback’s types declaration file here.

Reference:

https://webpack.js.org/plugins/split-chunks-plugin/

https://www.iamtk.co/webpack-bundle-splitting-and-browser-caching

https://indepth.dev/posts/1490/webpack-an-in-depth-introduction-to-splitchunksplugin

[embed]Webpack: What is the difference between "all" and "initial" options in… Extending the example shared by @Sujaan Singh, and consider splitChunks.minSize equal to zero. These are the files that…stackoverflow.com

[embed]Webpack 4 — Mysterious SplitChunks Plugin The official release of Webpack-4 boasts about the proven faster build time (around 98%) and reduced chunk sizes.medium.com

[embed]Webpack (v4) Code Splitting using SplitChunksPlugin Introduction to code splitting in Webpack v4 and with import() function → lazy loading routes in React using React…medium.com