Managing Your Bundle Size - Totally Tooling Tips

Key Takeaways

[Music] hey books so today we're gonna 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 projects is there a few different ways that you can do this if your projects 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 and the idea behind bundle size is that you know once you've got to configure you can say well I've got these bundles I've got like a tender bundle I've got my main application logic ones and I don't want those bundles to exceed a certain size and so you know if people are filing PRS against your project it's very easy to see where the following off tell them you know hey this is crossing our budget for JavaScript bundle size please make your code smaller the nice thing is well I think it actually reports like what this like the PR size would be in terms of particular like this file is this size this father size even if you're not reaching your threshold maybe you could say Ashley this is a huge jump compared to I saw last PR so yeah yeah the other side you it doesn't have to be a bundle right that you could just say this javascript file what size is it yeah yeah just just checking yeah it's it's pretty nice and it works off of gzip sizes as well so you get a picture into your what the final final size might look like nice so that bundle size took me like only 10 minutes to setup on one of my apps fairly low friction mostly works off your package a JSON file folks check it out you did in looking at some of the stuff too yeah so with work box we kind of have a file size kind of concern and we've been trying to like figure out how we can actually stay on top of it because it 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 what we'd like it to be so we're working on a rewrite and part of that is let's get it into our CI 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 the idea I think we took from Mosin lyft where it's he's actually like written a little bot that would say this is the change for this PR has it gone down has it gone up and started like flagging thresholds around the percentage of increase or decrease so I've been making my own little buck thing so we can do the same thing and maybe some additional stuff as well with little plugins the idea is just to help we're tracking like what is master what is this pull request doing and then adding like 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 I don't know like I think muslins 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 the deci I yeah I would love to see more people like more teams integrating this since their workflow I think it's 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 um they're they're combining sort of bundle size impacts measurement with lighthouse measurements as well so keeping an eye on all their runs which is kind of kind of nice to see it's almost as if there's a tool that would take plugins and run out and get hub would just be super useful right now so another thing you can do if you're locally developing is we worked on this feature with web pack called performance budgets and the idea is that you were able to set the budgets that you want you and your teams follow for your different bundles so by default web pack uses a bundle size of about 250 kilobytes your team I have something a little bit more specific a little bit smaller a little larger but this feature is just great for you know every time you're working on a change you're trying to do a local bill 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 it 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 you can it can do a warning it can also throw it as an error as my understanding so noise god you've got your your basis covered there yeah so that's web packs performance budget features something we saw this week that was kind of neat was another tool call it's a plugin for Visual Studio code yeah called the vs code import cost extension and one of the really nice things about this is that it can display in line 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 line that says you know like low - just 70 kilobytes or I was gonna say this is like highlighting the sure that we flaked up a couple of episodes ago around using particular plugins to help you get around sort of file size things and this is a really nice example where it actually flex it like right in your editor which is awesome yeah and this is running like the ability by pac plugin behind the scenes so it's four es module style packages it's going to at least be giving you an approximate for what the minified size is going to look like okay we've also been talking to them about maybe highlighting the gzip size but it's still it's still a good gut check for now yeah I don't know I think anything where it immediately makes you think okay I'm about to require this third-party module it's instant like well this is the hit you're 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 to get services for this our speed curve and caliber so caliber these are kind of tools way you say this is my website and they'll keep on like pinging it on a regular basis run a load of tests on them and then kind of report on a 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 like basically sending down different assets based on like media queries or user agents or what-have-you exactly nice so if a member of your team accidentally pushes out like a feature that's got a lot of JavaScript in there that's gonna you know decrease time to interactive you know 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 yep that is 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 want to check this stuff out locally then I got it then go to CLI they got the pour requests and then they've got actual production regular testing yeah and it's worth saying like it's worth doing this stuff up front because a little bit of effort now should help you in the long term because it's just regularly tracking and you don't there's no babysitting it's just you know if these things so just definitely check these tools out yeah these tools are awesome for helping you you know just make sure you're stripping the minimal amount of JavaScript to your users you know defer the rest that work until later point in time but yeah try them out let us know what you think Thanks [Music]