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 "Code Splitting" 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:

Large applications often contain modules that are not required initially. Code splitting is the process of separating out lower priority modules to make the application bootstrapping faster. These modules can then be lazy-loaded once they are needed. Kent introduces the concept of code splitting and talks about why it can be beneficial.

Get Unlimited Access Now

Transcript from the "Code Splitting" Lesson

>> [MUSIC]

>> Kent C Dodds: Okay, this is one of the earliest features of Webpack. This is actually, this feature is why Webpack was originally created. Tobias decided he needed some capability to only load code when it was needed. And none of the bundlers really handled that very well. You'd had to do a lot of stuff yourself.

[00:00:23] And so, he created bundler, this [LAUGH] amazing guy created a bundler just to handle that use case. And so, you can imagine it like this. I'm on the mobile or I want to go to Twitter. And so, I'm on my own mobile browser and I say, okay,

[00:00:44] The last thing that I, as a user, want to do is wait. And so, all that I care about is what's gonna be on my screen when I get there. And so, what codes, the whole why around code splitting is get things to the user as fast as possible.

[00:01:00] And that means as little code as possible, we should be sending as little code as possible to the user. And so, when I log in, now, suddenly, I need all of the code for the login. So, if this is like a single page out, then, I need all of the code for the Twitter stream, and I need the code for settings.

[00:01:20] And, well, even potentially settings could be, yet, another area where I load stuff in late. So, the whole idea around it is only load the code that's needed for where the user is going. And so, that is totally possible and actually, fairly simple with Webpack. You'll notice over here on this previous step, we're checking out a separate branch.

[00:01:49] So, originally, we went to tree shaking branch to get the tree shaking stuff. We're actually skipping over another branch because we're gonna actually considerably change the app in ways that aren't totally relevant to you. So, we're actually adding react in to the app now. Let's say that for some reason, if you check out that branch and run the dev, stuff here, then, you'll get a nice, new pie chart.

[00:02:21] You click on that and it will show you a percent of your completed and incomplete tasks, which is kind of fun. And this is all using react-d3, two enormous libraries. So, if I am on this, actually, if I look at my Network tab here, I refresh the page.

[00:02:46] I'm not using the the chart. Maybe, I'm just coming here to check off a quick to do. I don't care about that chart. I'm still loading 2.1 MB. This is in development, but in production, that'll still be of considerable size, mostly, because of D3 and React. And so, I want to load this stuff as late as possible, only when the user navigates to those, to that graph.

[00:03:13] So, any questions about the why behind me on code splitting? Makes sense? Okay, so, I should mention also, this is one of the features that I actually, I think, I'd mentioned earlier, that you probably would have a hard time doing with Angular one. Because Angular one needs all modules defined up front.

[00:03:32] And all the components and everything needs to be defined up front. And implementing code splitting is not trivial with Angular one. I spent a week on it and it failed. So, you have to structure your app in a really specific way. Something like Backbone or React is a lot easier.

[00:03:54] Daniel U asked, Kent, can you give some advice on speeding up Webpack with pre-fetched plugin or DLLs? Do you use any of these? I actually don't use the prefetched plugin or DLLs. We will look into some sort of alternative solutions a little bit later. And Henry is asking, is this features the same as critical CSS path rendering?

[00:04:18] Not exactly. So, earlier, when you're talking about how we got that flicker. And so, we just put the JavaScript in the head to avoid the flicker. And that was kind of cheating because you shouldn't do that cuz in a bigger application, the user is just going to see a white screen until all the JavaScript and everything is loaded.

[00:04:35] So, it's better to just put the stuff that's important in the head. So, it is a little bit different. You could potentially accomplish the same thing. Once we get a little bit further along, you could use Webpack to accomplish a critical CSS stuff. And you actually could use code splitting to do that as well.

[00:04:58] Yeah, actually, and I think about it. Yeah, you could totally use code splitting to just load the critical stuff first, and then, load the rest of your app later. And Webpack, the answer is always yes with Webpack.
>> Students: [LAUGH]
>> Kent C Dodds: It's always yes.