This course has been updated! We now recommend you take the Complete Intro to React, v7 course.

Check out a free preview of the full Complete Intro to React, v2 (feat. Router v4 and Redux) course:
The "Code Splitting with Webpack" Lesson is part of the full, Complete Intro to React, v2 (feat. Router v4 and Redux) course featured in this preview video. Here's what you'd learn in this lesson:

Brian introduces a feature of Webpack called code splitting. Code splitting gives developers the ability to separate application code into multiple bundles. The application will only download the bundles necessary to render the initial view. As a user navigates the application, additional bundles are loaded on-demand.

Get Unlimited Access Now

Transcript from the "Code Splitting with Webpack" Lesson

>> Brian: And now we're gonna do code splitting, which is another really, really cool thing. But this is specific to Webpack but it is surprisingly easy.
>> Brian: So if we look at our app here, my last render had,
>> Brian: 1.4 megabytes of code. Now granted, this is the dev build, right?

[00:00:24] But nonetheless, that's really big, right? This is a stupid app, and it's a megabyte of code, which is ridiculous. Furthermore, we have the interesting problem that I load this page for the very first time, so I load the landing page. I also get all of the code for details, and I get all of the code for search as well, which I don't need.

[00:00:47] I don't need those until later. So, it would be better if I could split those up into different chunks that get loaded progressively, as I browse it at the app. Luckily, Webpack kinda does this for you for free, if you, kind of s ignal to Webpack, here's a point where you can cut.

[00:01:04] And it's smart enough to figure out, okay, you cut off this part of the dependency graph. So I'm just going to shove this, everything that this depends on, and nothing else depends on. And I'll only load those when I need them. So, let's go give that a shot.

[00:01:20] So, go to Webpack.
>> Speaker 2: Quick question. Francois is asking basically, is universal rendering is one way to not have to configure routes on the server. Are there other ways?
>> Brian: So yes. So one of the big wins I probably should have hit on a little bit more. Is, notice that we didn't have to do any sort of routing here on the server, that it's actually reading from the routes from the browser.

[00:01:49] So, we wrote our routes once, and it works both on the server and the client. That's a huge win, right? So, our friend is asking if there are other ways to accomplish this. I think the only way that I can conceivably think to accomplish that is that React router has another way of configuring it.

[00:02:11] We configured it with the jsx way. There's also a way that you can pass it a config object. And so you can config your routes there and pass it to both in the client and the server and that would work as well. Other than that you would have to duplicate the routes everywhere.

[00:02:30] That's all I can think of anyway, or use another router. Yeah, if you don't have to worry about react router, the server side rendering code is even simpler, right? In fact I think I can show you just super quick. This is another workshop I've given before. I just wanted to show you, completed, app.js.

[00:03:03] So this is using co-op, which is an Express like. But this is it right here if you don't have to worry about React Router, renderToString, send it down.
>> Brian: That's it, that's all the server side rendering code if you don't have to worry about React Router. React Router just has a bunch of additional concerns.

>> Speaker 2: A question, will the server side rendering be good for SEO as well?
>> Brian: Yes, so yeah the Google bot can just pull down HTML and it can do all its crawling of that. It doesn't have to know that it was server side rendered or anything like that and it makes SEO much better.

[00:03:45] It's actually probably one of the biggest wins, I just don't think a lot about SEO.
>> Brian: All right, so let's go back to code splitting.
>> Brian: So come back to your Webpack config. The first thing you'll have to realize is we're gonna start splitting our code into multiple bundles.

[00:04:04] But we have to let Webpack know, hey, here's where you serve those bundles from. Right, cuz it's gonna download the first bundle. And then you need to tell it the additional bundles will be here to download them. So we just have to give it a public path, which mind you,

>> Brian: no, it's here in the output. So here, inside of output, which is different than devServer. I know devServer has a public path, but output also needs a public path, which is also the same thing.
>> Brian: So publicPath:/public/ inside of the output config object. Again just letting Webpack know as once you've downloaded this is where you get additional bundles.

>> Speaker 2: Martin is wondering why is the async rating loading so slowly now?
>> Brian: I don't know if it's loading any slower than it was. Check it and call your ISP. I'm just kidding. Blame Comcast.
>> Brian: Well, if you're loading the page, it has to do service side rendering.

[00:05:26] It has to send it down the wire, it has to load the HTML, parts the JavaScript. React has to bootstrap, your app has to bootstrap. At that point component will call, and it'll make that call. So that might be 20 milliseconds slower, 100 milliseconds slower, depending on your internet speed.

[00:05:43] So for me it's not perceivably any slower, but we're on fast wi-fi, so. But it could be a bit slower,
>> Brian: Or maybe OMDB is just being slower right now.