 So today we're going to talk about Webpack performance tips. Performance of the JavaScript you're serving up in the browser, not Webpack itself. So let's start off with minification. You should be minifying any of the code that you're sending down. With Webpack, there are a few interesting nuances there. First thing to do if you're shipping ES5 code is to use the Uglify.js plugin. Folks are probably aware of that from other projects pre-Webpack. Yeah, Uglify.js is the standard one, yep. Now, where you have to get a little bit creative is if you're shipping anything other than ES5 down to your user. So a lot of folks are writing ES2015 today. If you're doing that and not transpiling down to ES5, make sure you're using something like Babilly and the Babilly Webpack plugin. Yeah, so it's going to minify, but it also understands ES2015, so there's certain optimizations it can do because it understands it's a little bit better than Uglify.js. Yeah. Next thing folks should make sure they're doing is minifying their CSS. Now, it sounds very straightforward. However, if you were loading in any CSS using Webpack's CSS loader by default, it's not going to minify that code. Effectively, you're putting one type of file format into another that's going to get stuck into your JavaScript bundles. So make sure that you're passing minimize true to that. So at least whatever you're putting in there is at least small. Exactly. Ideally, you don't have to think about that because you're actually extracting your CSS to a completely separate file. That's our preferred option. There are benefits to that. You don't have to double parse. It doesn't have to parse your JavaScript in order to parse your CSS. It's also going to cache a little bit better on the browser side of things because you're not going to invalidate your bundle every single time. You're making a change to your CSS or your JavaScript. You're keeping those things pretty separate. In Webpack, use the extract text plugin to get that working. Cool. Sounds good. Next thing, take advantage of ES module imports for tree shaking your dependency graph. Yeah. What is tree shaking? I'm still figuring this out. So tree shaking, one way or another is where I can remove dead code in terms of your imports and exports because if you import something and there's a ton of other exports you don't use, they can be removed. I believe, though, if you import one thing from a file, it'll import all of the exports, but then it will tree shake beyond that. I don't know. There's some funky stuff. There's lots of nuance to these stuff around tree shaking. But it's still good and then we'll remove code you don't use. In Webpack, one of the lesser known things is that unused code itself is not removed by Webpack. It's done by a minifier like Uglify.js. So Webpack is just gonna remove your export statements that are used for exports that you're not actually using. You still need to use a minifier to get rid of the rest of that code. So make sure you're using. Just any dead code paths that it knows is never gonna actually run. Exactly, exactly. Another useful thing is making sure that you're running Webpack in production mode. Yes, this is the Webpack thing that I was very confused about when I first heard about it, but it kind of makes sense. Yeah, so two ways to do this. You can pass the dash P option to Webpack itself which will take care of both minification and setting your node environment variable to production effectively. Another thing you can do is use the Webpack define plugin to accomplish the same thing. That's how I usually do it. I totally forgot Webpack dash P was a thing. So define plugin is good for slightly more complex cases. I just JSON stringify my production settings and just have it do the thing. Useful for when a library has to switch between like the dev or debug builds over to the production builds. Yep, all sounds good. Another thing that's useful is taking stock of what you're actually shipping down using a bundle analyzer or a source map explorer. So lots of good tools for this stuff can help you identify whether you're shipping code that you didn't expect to be shipping down to your users, whether there are like modules that you can maybe switch out for much smaller alternatives. It's always good with the body code because you'll eventually get an overall picture of where all the size is actually coming from and then get a feel very easily of what percentage is coming from where. Another good thing to do is splitting up your vendor libraries into a completely separate bundle, separate chunk. Now your vendor libraries are things like your framework code, your library code that you're going to be reusing across a bunch of your different routes and views, stuff that if you move into a completely separate bundle the browser can cache and you're probably not going to update that code. Yeah, the only time it's really going to change is if you bump up the framework version or a library version. Otherwise, yeah, it's going to be the same. Yeah, so take out the webhack commons chunk plug-in for getting that set up. Related to that is code splitting. So what is code splitting now? So code splitting is where you're actually taking all of your code and rather than munch it together in one single file and shipping it down, you split it up into several files and then you actually only pull down the most important bit and then you can async load in the other bits. Exactly, so the idea is that you're just shipping down exactly what the user needs for the current route or the current view and the difference between using a static import and getting this done is that you're going to start using a dynamic import. This is a newer JavaScript feature. The idea is that you just want a lazy load in pieces that don't need to be loaded up front. And so that allows you to basically move this out into code that can be deferred load later on in the process. Oh, okay, so that is actually the dynamic import standards thing. Yes. And webpack just supports it. Nice. You can also take advantage of dynamic import with things like React, lots of different things like React Router allow you to use it inside Get Component. But that ends up being more specific to your framework of choice. Now, another thing, I see a lot of people trip up on, libraries like Moment.js, like the DateTime library. Yeah, use that a lot. If you include it by default, it's got a relatively large size. It's something like 215, 216 kilobytes. And that's because a lot of that file is like it's localization stuff. Okay, yeah. And unless you're like a really large international site, you might not need to be loading all of that stuff up front. And even if you need it, you could probably be lazy loading it in or making intelligent choices. Yeah, you can probably do different bundles anyway for the localization, which you might be doing already. Yeah. Exactly. So in webpack, check out the context replacement plugin. What that will let you do is basically you can pass in this magic regex to the bundler and specify what locales you do wanna support. Like maybe I wanna support, you know, English for the UK and the US, but ignore some other ones. And that just will save you a bunch if you happen to be using these types of libraries. It kinda just globs whatever files are inside that library and then just only pulls those in and ignores everything else. Effectively. Nice. Lodash, popular JavaScript utility library. We definitely use it a lot in our projects. Lodash is pretty modular by default. So you can, you know, pick the methods that you want and just import in exactly what you need. But I still see a lot of people importing in like all of Lodash and every utility it's got. That's kind of the whole point, right? Like you're just used to having like the underscore there that just has all the utilities on it. It makes a lot of sense. Exactly. One really neat package you can use is a Lodash webpack plugin or Babel plugin Lodash. And the idea there is that it'll, it's a transform that will rewrite your code to only include the specific parts of Lodash that you're using. So you're not including the entire thing. So it's just gonna swap out your code for underscore.get and it will actually just go, oh, you're only using get. So I'll just pull in that one thing and then rewrite your code to just use that one thing. Exactly. I tend to find that it, it turns down my Lodash portion of my bundle down to about 10% of what it used to be. So it's a nice little saving. Very nice. There are lots of other tips that folks can check out. But we're gonna link you to a bunch of different blog posts and guides that you can go and read up. Yes. If you've got any questions, feel free to direct them. Not to us, but to Sean Larkin on Twitter. Hi Sean. Now we're more than happy to answer any questions. That's a webpack performance. Yeah. One day I'll get around to learning it. You could just watch this video. Just watch it back. Nice.