 So we previously did an episode on JavaScript module bundling lies and then you spent three weeks crying in a corner Because we did that show mm-hmm And then someone actually brought out the thing that we said was a joke I can't remember what it was. It was like roll up web pack of fire Some weird mix of stuff and then it became a thing Frankensteins JavaScript monster. It was great I would actually love it if a module came out that was Frankenstein.js or something. It probably is it's probably a library Yeah, anyway, sorry, what where are you going? Today I wanted to talk a little bit more about web pack and specifically giving people three tips I've been doing some research recently into react and sort of web performance on real-world devices And this is sort of backed up by the survey that I did where I asked people, you know What are you doing with react in production? Are you using web pack web pack ones who browser fire? What are they were bundling or not and how they were picking it and yeah Yeah, what I discovered was that a lot of people a lot of people confused by code splitting But concepts like code splitting some people are using it some are not some are using it and then not entirely Understanding how to do it, right? So I wanted to quickly cover some of the concepts there in case it helps So do you know what code splitting is? That's the way that you basically this this window or this bundle should consist of these files, right? And then you kind of say so that's gonna be bundle one that's gonna be bundle two That's gonna be on the three so right splitting is the act of deciding where those lines are right And if you're doing it intelligently, maybe you're just going to you know Ship down the smallest amount of JavaScript necessary for a route or a view to users and then lazy load in the rest This isn't this isn't a new idea Gmail did it like a million years ago in web pack It's pretty I would say that once you know how code splitting works is pretty trivial to do on every project But it's getting to that point that requires you to read like a bajillion blog posts So you're gonna do it in this five to I'm gonna cover in 15 seconds So in web pack if you're using required insure in your web pack one code It'll basically allow you to apply code splitting if you're using web pack to you can use system import to do the same thing So if it detects that you're using that it'll allow you to basically Split up that bundle based on that particular blob of JS being used So every time it runs into a required insure for say a view it'll put that code into a new chunk And if you navigate to that chunk So if you happen to be using web pack with things like react router, for example It plays in really really nicely You can just load in the JS necessary for a route and then lazy load in the other pieces as needed where people get tripped up here is Either they'll You know, they'll use code splitting or they'll think they'll use code splitting because web pack also supports this other idea Called the commons chunk plug-in. So the commons chunk plug-in. So normally in an app Let's say you're using you know libraries or frameworks or whatever, right? You can have multiple views some of what you're gonna have similar code, right? And that's sort of your vendor bundle, right? And that's code that you may need to load up up front in order to get you know the route useful in any way It might be your load ash or your react or whatever have you this is kind of the stuff that has to be loaded No matter what and it's common enough that it should just even if it's large It's kind of like okay take the hit because every single page is gonna right exactly So the commons chunk plug-in helps you basically split out the stuff that's common between your different modules Into a common vendor bundle, right? So that's tip two now where people are running into issues with code splitting is that they're splitting their code But there's still in many cases shipping down a huge blob of JavaScript that they don't necessarily need for just the stuff That route's gonna do So I'm why what I was seeing in the traces I was profiling was some people are shipping like up to a meg of JavaScript just for a single route And is this because they've got a large vendor? JS like a large common vendor JS or is it just a mix of things sometimes? It's a large vendor bundle where they're like just happening to ship down You know libraries that that route doesn't need in other cases It's where they're loading in stuff for other routes By accident or just not not being particularly diligent about what they're including in the main chunks for each view So that's a good thing to stay on top of just keep in mind You know what size webpack has got this way of like summarizing all the chunk sizes when you're doing code splitting Yeah, and the report of you just keep an eye on those sizes. We're currently we've been working on an RFC For webpack to maybe try providing you like performance inside to performance budget of some sort And if something like that lands I think it'll hopefully make it a little bit easier for people to know that they have an issue thing I saw you're looking at where it might show like a red line going this is X amount of like kilobytes or megabytes And you should seriously consider breaking it up. The other tip was if you happen to be using HB to there is another webpack plug-in called the aggressive splitting plug-in. Just sounds really violent Yeah, I was gonna say that doesn't sound like something I'd want the aggressive splitting plug-in basically gives you a way to Split up your chunks with a maximum and minimum size so you can specify exactly what? It's like upper bounds you want and it will figure out some magic around that to make those those work Sounds very risky. I don't know. I just the idea of like, oh, you've reached a certain max size so chop in half And don't worry about it. It works in practice I think it's definitely something that people need to spend a little bit more time on but It it's supported. It's good to know that webpack is sort of exploring the ideas around h2 I think that in addition to sort of so we've talked about three tips We talked about code splitting common strong plug-in aggressive splitting plug-in as always because we're all about the service worker If you're gonna if you're gonna use all these libraries and things in your builds these days It's great to not have to pay any you know as much cost to the user to like load them up again on repeat visit Yeah, so, you know, there are plugins like service worker pre-cache webpack plug-in Yeah, which let you use service worker pre-cache, which we work on then this beautiful just build your service worker for you Think about it saves you users time when it comes to that repeat visit. So check that out as well Plenty more webpack tips and some of the articles that we've been tweeting about lately and writing So check those out because I believe you've been writing a lot on medium lately. I have been writing a lot on medium People can check that stuff out if they so please. Those are just a few webpack tips and hopefully they will come in useful