In this article, I'll show a benchmark of build time with and without chunk splitting.

Chunks

Chunks are parts of the build that can be reused between different entry points. This is especially useful for the users of the multipage websites - as shared code should be in shared chunks that can be cached and reused between pages. This gives less transfer use for both the users & the server.

The less obvious impact is the build speed up, and I'll focus on this here.

Code

As the application, I have 10 files like src/a.js:

import $ from "jquery";

$(".a").html("a");

Simple webpack configuration

The basic configuration webpack.no-chunks.js:

$ time npm run webpack:no-chunks
...
> webpack -c webpack.no-chunks.js
...
asset a.js 88.2 KiB [emitted] [minimized] (name: a) 1 related asset
asset b.js 88.2 KiB [emitted] [minimized] (name: b) 1 related asset
asset c.js 88.2 KiB [emitted] [minimized] (name: c) 1 related asset
asset d.js 88.2 KiB [emitted] [minimized] (name: d) 1 related asset
asset e.js 88.2 KiB [emitted] [minimized] (name: e) 1 related asset
asset f.js 88.2 KiB [emitted] [minimized] (name: f) 1 related asset
asset g.js 88.2 KiB [emitted] [minimized] (name: g) 1 related asset
asset h.js 88.2 KiB [emitted] [minimized] (name: h) 1 related asset
asset i.js 88.2 KiB [emitted] [minimized] (name: i) 1 related asset
asset j.js 88.2 KiB [emitted] [minimized] (name: j) 1 related asset
...

The time output:

real    0m9,514s
user    0m29,585s
sys     0m0,410s

The build takes about 9.5s.

Webpack configuration with chunks

The optimized configuration has a small change, webpack.chunks.js:

$ time npm run webpack:chunks
...
> webpack -c webpack.chunks.js

asset 755.js 87.9 KiB [compared for emit] [minimized] (id hint: vendors) 1 related asset
asset b.js 1.17 KiB [emitted] [minimized] (name: b)
asset c.js 1.17 KiB [emitted] [minimized] (name: c)
asset d.js 1.17 KiB [emitted] [minimized] (name: d)
asset e.js 1.17 KiB [emitted] [minimized] (name: e)
asset f.js 1.17 KiB [emitted] [minimized] (name: f)
asset g.js 1.17 KiB [emitted] [minimized] (name: g)
asset i.js 1.17 KiB [emitted] [minimized] (name: i)
asset j.js 1.17 KiB [emitted] [minimized] (name: j)
asset a.js 1.17 KiB [emitted] [minimized] (name: a)
asset h.js 1.17 KiB [emitted] [minimized] (name: h)
runtime modules 30.5 KiB 50 modules
... 
webpack 5.51.1 compiled with 1 warning in 2367 ms

real    0m3,023s
user    0m5,646s
sys     0m0,198s

The build took about 3s, i.e., it was 3 times faster than build without splitting chunks.

Summary

As we could see in this small experiment, chunk splitting is not only beneficial for the users of our pages, but it's speeding our build as well. If you want to use it in your application, you will probably need to look at HtmlWebpackPlugin as well.

I'm building a webpack course. Currently, you can register for free, and keep the access even when the course will grow and become paid.

What is the performance impact of chunk splitting in webpack

Comments

webpack optimization

How to speed up webpack with esbuild-loader

More from this blog

Changes in programming made possible with AI

Advantages of unit testing—with examples in Jasmine

Pure functions and basic tests in Jasmine

How to prepare for a job interview

How to build a demo project

Chunks

Code

Simple webpack configuration

Webpack configuration with chunks

Links

Summary

Command Palette

Comments

webpack optimization

How to speed up webpack with esbuild-loader

More from this blog

Chunks

Code

Simple webpack configuration

Webpack configuration with chunks

Links

Summary