One of the most effective ways to improve page performance is to ship smaller JavaScript bundles. Simply put, send less code to the user's browser. In this lesson, we'll explore how to do that with a concept called tree shaking. Let's start out with a practical example inside of our view project.
json file that lives inside of our view project. And within the dependencies section, you can see that we have Lodash installed. This is a popular utility library that is common amongst projects in JavaScript land. Now we also have an alternate version of Lodash installed just below this, but don't worry about that for now.
We'll get to that in just a moment. Next, over in the source directory of my view application, and then in Views, and then to-treeshaking-begin, I have the underscore abbreviation for Lodash imported from the Lodash library. I'm initializing an array of items to just 10 numbers, zero through nine, and then I'm using the Lodash shuffle method in order to shuffle those items. Over on the right-hand side, you can see the result of this.
We just have an array of shuffled numbers on the page. Now though, let's build our view application to see the size of the final JavaScript bundle that's sent to the browser. I'll do that by opening up my terminal, making sure I have the view app folder active, stopping the development server and then running npm run build. Perfect.
Next, I'll find that disk directory that was generated inside of the view app. And for me, I'm going to say reveal and finder. I'm on a Mac, you should have something similar on Windows. This opens up that disk directory inside of my Finder window inside of the Mac.
And then I'm going to look for the assets directory. And here you can see a number of different JavaScript files. This is because in our boilerplate code for the project, we are doing what's called code splitting. And we'll talk about that more in the next lesson.
But what I want to focus on for this lesson is the JavaScript file that starts with the word index. This is the main bundle for our application. And here you can see on the right-hand side that it is 169 kilobytes. Okay, remember that number, 169 kilobytes.
Back over in our code base, let's try making our bundle a little bit lighter by only importing the shuffle function instead of the entire Lodash library. That syntax looks something like this, which means, of course, we need to update where it's called down below. Okay, perfect. Let's build the application one more time and then we'll check out the size again.
Still 168 kilobytes. Nothing has changed. I thought using this syntax right here would mean I'm only importing that single shuffle function as opposed to the entire Lodash library, but that is not the case. This syntax will only work properly to include that one function if the package that we're importing from actually supports tree shaking with ES modules.
The plain Lodash package does not. That's why I've also installed the Lodash ES package. Doing this should reduce the size of our final bundle as Lodash ES is built to support tree shaking. Let's run the build one last time.
Awesome. Now we've moved from 168 KB down to 95 kilobytes. This is great. That's almost a third of our bundle size saved just from choosing the proper dependency.
The takeaway here is that you should choose your dependencies wisely and always prefer those dependencies that are tree-shakeable. Tree-shakeable, simply meaning that the library allows unused code or dead code to be removed from the JavaScript bundle. So that begs the question, how can you tell when a dependency is tree-shakeable. Most libraries that are will usually tell you right up front inside of their documentation.
For example, the Vue use docs listed as a feature right there on the home page. js docs mention it on their performance page. It even explicitly explains that all the composition API functions like ref, computed, and watch, as well as the built-in components like transition, are all tree-shakeable. So if you don't use one of those core view features, it won't ship to the browser.
Simple as that. What about for libraries that don't mention anything about tree shaking in their docs? Is there any other way to tell? Let me tell you real quickly about a tool called BundleJS.
com and is a quick way to check npm package sizes. So its main purpose isn't to check if a library is tree-shakeable or not, but we can use it to that end. Let me show you how. First, I'll type in the package that I want to check.
Let's just continue to go with Lodash. Then I'll click Add Module. Down inside of the code editor below, I'll remove this second line and then just export all of the utility functions from Lodash like this. I'll hit Build.
which is basically the same thing as us building our view project. 8 KB. Now let's try just exporting the shuffle function and hit build again. 8 KB.
Therefore, no matter how we write this export statement, the size of the bundle doesn't change. So low dash core, Lodash, the original, is not tree-shakeable. If we search for Lodash ES, add that, and then remove our export of the original Lodash library there, let's try building our bundle now with all of Lodash ES included. 3 kb.
Interesting, that's actually a little larger than the original Lodash library. But... I think you know what we're going to do next. Now let's include just the shuffle function.
Perfect. 8 KB compressed. So if you try to export just a single function and all of the library and you get the same size for both, then that library is not tree shakeable. But if you can export the entire library at a higher size and then just try exporting a single a function from the library and it lowers the size, then you can tell at that point that the library is tree-shakeable.
Finally, this concept of tree-shaking applies the same in the context of a Nuxt application, so there's nothing really new to explain there. But it might be worth mentioning that Nuxt does have a Lodash module to take care of all of your Lodash needs. So definitely reach for that and make sure everything is tree-shakeable for you. when you're working in a next application.