Check out a free preview of the full Introduction to Gatsby course:
The "Analyzing Gatsby Bundle Sizes" Lesson is part of the full, Introduction to Gatsby course featured in this preview video. Here's what you'd learn in this lesson:

Jason installs gatsby-webpack-bundle-analyzer and uses the plugin to view the bundle sizes being used on the site, along with discussing what to look for when running the analysis.

Get Unlimited Access Now

Transcript from the "Analyzing Gatsby Bundle Sizes" Lesson

[00:00:00]
>> Jason Lengstorf: We're kind of coming up on the end here. So the last thing that we really want to do is make sure that we didn't do anything silly. So the way that we're going to do that is we're going to check the output and make sure that the bundle that we built is only including stuff that we actually need.

[00:00:18] And a lot of projects like any time that you're using a bundler or something like webpack or anything like that. A risk that you run is accidentally including a whole bunch of stuff that you're not actually using. So the way that we are going to solve this problem, we actually don't even know if it's a problem.

[00:00:37] The way that we're gonna see if we have this problem, is we're going to install a new plug-in. And this plugin is called, let's do NPM install.
>> Student: You have to unfreeze.
>> Jason Lengstorf: Gatsby, let me unfreeze. Here we go. Okay, so we're gonna install a new plug-in. That plugin is called gatbsy-plugin-webbpack-bundle-analyzer and we're going to let that install.

[00:01:08] And as this installs, we're going to close things down and get back to just our Gatsby config.
>> Jason Lengstorf: And we can just drop this in,
>> Jason Lengstorf: Pretty much wherever we want to here. Let's,
>> Jason Lengstorf: Drop this right at the bottom. And so what we're gonna do is resolve the gatsby-plugin-webpack-bundle-analyzer and we're going to set some options on this.

[00:01:53] The first one is we want this to run on our production bundle. It's not super useful on the development bundle because when we're running and Gatsby developed, we're not actually doing the optimizations to. We want hot module reloading to work. So we're not gonna do all that work to split the bundles and stuff it would it would be too slow.

[00:02:13] So in production mode, that's what we wanna check. Also, we wanna make sure that we don't run this all the time. So we're gonna make sure that it only runs if we set a an environment variable. So we're going to set process end and we're gonna call this ANALYZE_BUNDLE_SIZE.

[00:02:31] So if ANALYZE_BUNDLE_SIZE is true, it will work. Otherwise, it's going to disable this plugin. We want to generate a stats file, singular, generateStatFile, is true. And then, we also want to set the analyzerMode to static. And all of these options are kinda, don't worry about them too much because this is where we start getting into web pack stuff.

[00:03:05] We're now doing web pack config through a proxy config which is don't overthink it. [LAUGH] Basically, what we want is we want a way to look at visually what's in our bundle. So now that we have this, I'm gonna open up the package.json, and I'm gonna add a new script here.

[00:03:28] And this script is gonna be called analyze. [SOUND] And inside of it we're going to use. If you installed cross end if you're on Windows you're going to use cross end. I'm going to use to show it. You don't need this if you're on a Mac though. So I'm going to do ANALYZE_BUNDLE_SIZE equals true.

[00:03:53]
>> Jason Lengstorf: And then we're gonna do gatsby build. So if you're on a Mac, you can leave this part out and it will work. If you're on Windows, that's just gonna make sure that the environment variable actually gets picked up. But you do need to make sure that you have cross end installed or else its not gonna work.

[00:04:10] So once we've got this running, what we can do is jump into our I term. And I'm going to do npm run analyze. And so we can see appear that it does run, ANALYZE_BUNDLE_SIZE true with gatsby build. It's doing all the build stuff that we want it to build and then it opens up this report.

[00:04:36] So this report that opens up is a little intimidating to look at but what it shows us is kind of everything that's being used. And so what's important about this is that we can start to take a look and see are we including anything that we shouldn't be.

[00:04:52] A good example of a thing that you might find in here is all of Lodash. If you're using one or two Lodash functions, if you include them the wrong way, you'll end up importing the entire Lodash library which is hundreds of kilobytes. You don't need that. Moment.js is another one.

[00:05:10] If you import something from moment is huge. And so maybe you wanna refactor to use like date functions with load Ash you can refactor to use named exports from loadashes. And that will give you the clean up. Maybe you wanna use low dashes like lib slash get to get to the just the function that you need.

[00:05:33] There are a lot of different ways that you can clean this up. This isn't a performance. It's not a performance workshop. So we're not gonna go like super deep into this. But it's a way for you to look and see like, all right, we're pulling down, like 200 kilobytes of JavaScript.

[00:05:49] That's not an insignificant amount. Why is that coming in? So you've got react-dom, that's the thing that you expect. Core.js is another thing that we need emotion and reach, right? So all this stuff that we're seeing and stuff that we expect to be here, there are no surprises.

[00:06:04] And the same with the the components, we're also seeing, like, all right, these components are only bringing in what they need. There's no outside stuff getting all over the place. React helmet is only included once, which is good. Same with the background image in Gatsby image, they're only included once.

[00:06:21] We're not seeing them in multiple places. So basically it's a good way to just do a final visual check that like, whoa, why is this bundle five megabytes or something?