This course has been updated! We now recommend you take the Webpack 4 Fundamentals course.

Check out a free preview of the full Webpack 2 Deep Dive course:
The "Commons Chunking" Lesson is part of the full, Webpack 2 Deep Dive course featured in this preview video. Here's what you'd learn in this lesson:

Commons chunking is useful when only part of a codebase is updated regularly. Non-updated modules can be cached so users do not have to reload the entire codebase when updates are made. They only reload the updated modules.

Get Unlimited Access Now

Transcript from the "Commons Chunking" Lesson

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kent C Dodds: Let's talk about Commons Chunking here. So again we're trying to optimize the results of our web pack build, all of our bundles, to be as small as possible but also make it so that the browser can cash the assets for as long as possible. So say you have two files and one of them is, so the user loads both of the files and then you change only one of them, now the user only needs to load that one file.

[00:00:35] The other one is cached, right? So if you have some code that doesn't change very frequently this would be a really good candidate for putting it in the Commons Chunk, so that like any time you make changes to this other code that does change more frequently people don't have to re-download that.

[00:00:52] And so the browser has it in its cache and it loads much faster. So that's the idea behind behind Commons Chunking. Another kind of, to kind of conceptualize it, you can have multiple apps that use the same common files, like lodash would be a great example. I use lodash for every example.

[00:01:11] I should be more creative. jQuery, or React, or D3 some of these bigger things and vendor files go really well as a Commons Chunk. So then here's all the like, this is the bundle for app one, two, three, and four and those things are specific to these these different apps or these different pages.

[00:01:32] But then this is the JavaScript that's common between them and so the user goes to app one they load all the app one code. Then they go to app two, they only need to load the app. Well sorry, they go to app one, they load the app one code as well as the common stuff.

[00:01:47] Then they go to app two, they load the app two code but because they already went to app one they don't need to re-download that. The alternative of course being that app one itself has all of app one's code as well as all this common stuff and that's kind of what we have right now.

[00:02:03] As if we had multiple apps or something then we would like all of the all that stuff would be bundled together into each individual app and so they'd have to download that much for every single app that they go to. So this is a pretty common problem, and I'm pretty certain like I can't think of a single type of application where this wouldn't help.

[00:02:28] Yeah, pretty much no application this could be beneficial.