 Hey, folks. So today we're going to talk about keeping an eye on your JavaScript bundle size. Very, very important. We've already been hit under there by a number of projects. Number of projects. There are a few different ways that you can do this. If your project's on GitHub and you care about things like continuous integration, there's a nice little package called Bundle Size. You can drop in. It's also a CLI, so you can use it locally as well. Also CLI. Now, the idea behind Bundle Size is that once you've got it configured, you can say, well, I've got these bundles. I've got a vendor bundle. I've got my main application logic once. And I don't want those bundles to exceed a certain size. And so if people are filing PRs against your project, it's very easy to see where they're falling off. Tell them, hey, this is crossing our budget for JavaScript bundle size. Please make your code smaller. The nice thing as well, I think it actually reports what the PR size would be in terms of a particular like, this file is this size. This file is this size. Even if you're not reaching your threshold, maybe you could say, actually, this is a huge jump compared to why I saw the last PR. So yeah. The other side, it doesn't have to be a bundle, right? That you could just say, this JavaScript file, what size is it? Yeah. Just checking. Oh, that's all good. It's pretty nice. And it works off of Jesus sizes as well. So you get a picture into what the final size might look like. Nice. So that bundle size took me only 10 minutes to set up on one of my apps. Fairly low friction. Mostly works off your package.json file. Folks, check it out. You've been looking at some of this stuff too. Yeah. So with Workbox, we kind of have a file size kind of concern. And we've been trying to figure out how we can actually stay on top of it. Because we kind of did all this work. We released this thing. And now we're like, cool. What is the actual file size of this? And it's not where we'd like it to be. So we're working on a rewrite. And part of that is, let's get it into RCI. So that way we can just, whenever we do a PR, what is the current size? What is it now? And it's super nice to the idea. I think we took from Mohsen at Lyft, where he's actually written a little bot that would say, this is the change for this PR. Has it gone down? Has it gone up? And started flagging thresholds around the percentage of increase or decrease. So I've been making my own little bot thing so we can do the same thing and maybe some additional stuff as well with little plugins. The idea is just to help with tracking, what is master? What is this pull request doing? And then adding those similar sort of thresholds. Great. And one of the nice things about that is it's able to show you the before and after cost for every single file. Yeah, like, I don't know. Like, I think Mohsen's one was the first one where I'd actually seen it was like, ah, that actually totally makes sense. You should definitely have that. And everyone should just have it in their CI. Yeah, I would love to see more people, like more teams integrating this into their workflow. I think it's really tight. And another thing Lyft have been doing is, so we talked about Lighthouse and CI in one of our last episodes. They're combining sort of bundle size impact measurement with Lighthouse measurements as well. So keep an eye on all their fronts, which is kind of nice to see. It's almost as if there was a tool that would take plugins and run it on GitHub would just be super useful right now. I would. So another thing you can do if you're locally developing is we worked on this feature with Webpack called Performance Budgets. And the idea is that you're able to set the budgets that you want, you and your teams, follow for your different bundles. So by default, Webpack uses a bundle size of about 250 kilobytes. Your team might have something a little bit more specific, a little bit smaller, a little larger. But this feature is just great for every time you're working on a change, you're trying to do a local build, just being able to make sure that you're not exceeding your team's budgets quite as much as you could be. So this would do this at build time, and presumably does it throw an error or does it still let you build and deploy, but it's just like flagging it as an issue? So it can do a warning, it can also throw it as an error is my understanding. So you've got your bases covered there. So that's Webpack's Performance Budget Features. Something we saw this week that was kind of neat was another tool called, it's a plugin for Visual Studio Code, called the VS Code Import Cost Extension. And one of the really nice things about this is that it can display inline in your editor as you're working on your code, like the cost of imports as you're working on them. So it shows you like a little bit of a comment at the very end of the line. It says, you know, like low dash is 70 kilobytes. I was gonna say, this is like highlighting the issue that we flagged up a couple of episodes. So you've got to go around using particular plugins to help you get around sort of fire size things. And this is a really nice example where it actually flags it like right in your editor, which is awesome. And this is running like the Billy Webpack plugin behind the scenes. So it's for ES module style packages, it's going to at least be giving you an approximate for what the minified size is gonna look like. We've also been talking to them about maybe highlighting the GZIP size, but it's still a good gut check for now. Yeah, I don't know. Anything where it immediately makes you think, okay, I'm about to require this third party module. It's instantly like, well, this is the hit you're incurring from that, which is really nice, really useful. Yeah. So we talked about continuous integration. We talked about what you can do locally. Another thing folks might benefit from is being able to measure like in production what the impact of their bundle sizes are over time. Two good services for this are SpeedCurve and Caliber. So Caliber. These are kind of tools where you say, this is my website and they'll keep on like pinging out on a regular basis, run a load of tests on them and then kind of report on an ongoing basis, right? Pretty much, yeah. So one of the nice things about Caliber is that you're able to specify like your target devices. You can say, well, yeah, I'm targeting desktop and targeting these mobile devices. And it'll be able to show you your bundle size like over time like your JavaScript that you're sending down to people. So that's super handy if you're like basically sending down different assets based on like media queries or user agents or what have you. Exactly. Nice. So remember your team accidentally pushes out like a feature that's got a lot of JavaScript in there that's gonna decrease time to interactive, have an impact on your page performance. Or if they push out a pull request that means that everything is like way faster because the bundle size is smaller. Let's be positive. Yeah, yeah, that as well. Good way to see both, both wins and places where you should probably cry. But Caliber is really great for checking that stuff out. So hopefully folks have got their bases covered. You know, if they wanna check this stuff out locally, they've got it. They got the CLI, they got the pull request and then they've got actual production, regular testing. Yeah. And it's worth saying like, it's worth doing this stuff upfront because a little bit of effort now should help you in the long term because it's just regularly tracking. You don't, there's no babysitting. It's just letting you know of these things. So you should definitely check these tools out. Yeah. These tools are awesome for helping you, you know just make sure you're shipping the minimal amount of JavaScript to your users, you know defer the rest that work until a later point in time. But yeah, try them out, let us know what you think. Thanks.