Make Your Webpack Bundles Clean and Lean
Turn your Webpack bundles a lean, clean user friendly machine. Read on for a few tips on how to make your bundle smaller, and easier to use.
Join the DZone community and get the full member experience.Join For Free
Recently a member of the team noticed that certain parts of the application were serving up bundles of nearly 2mb! I was quite new to Webpack at the time and jumped at the opportunity to get to know Webpack better and see if I could try and solve the problem.
This blog is the result of that process - four simple steps to reduce the size of your Webpack bundles. If you are working on a large enterprise project that uses a lot of dependencies on the front end (including Webpack) then I hope my experiences will be useful to you on your own project.
The Problem With Choice
Obviously, there are downsides too.
The more libraries we incorporate into our front-end application, the more code that needs to be downloaded by the end user to access this functionality. More code results in bigger files and the user may be waiting longer before the application is up and running. The size of ReactJS alone is enough to make you weep.
In the UX world, site or application loading is still a major bugbear for users and quite often, one's first experience with a site counts. A user that experiences a slow site may not end up returning. Site loading times are an important consideration for all developers, but in large Enterprise projects, optimization can sometimes take on a whole new meaning and can be benchmarked in milliseconds rather than seconds.
Managing Dependencies With Webpack
Managing your dependencies is usually done with the help of another library. Webpack is one of a number of available tools that helps package all of your dependencies. Webpack goes through all your dependencies and can combine them into a single file (i.e., a bundle), applying useful transformations along the way. For example, removing any unreachable code, splitting your codebase, turning the code into something the browser can understand, etc.
The rest of this post assumes you have some familiarity with Webpack. If you are new to Webpack and you want an in-depth tutorial from the ground up then I strongly recommend you check out Survive Webpack. It’s a great tutorial that's ideal for coming to grips with Webpack basics.
To assist you in this tutorial, I have uploaded an example Webpack configuration that implements the steps below.
Now we are ready to continue.
Let's look at a process for making your Webpack bundles clean and lean.
Applying 'C.A.R.E' to Your Webpack Bundles
Yep. I came up with a cheesy acronym to sum up the key steps for making your Webpack bundles clean and lean (for which I do not apologize).
Question: What does C.A.R.E stand for?
Answer: Clean, Analyse, Reduce, Externalize
So in order to make your bundles smaller, go through the steps as defined in C.A.R.E.
Note: Even though I have specified an order here, make up your own mind as to what order makes the most sense for you.
If you are familiar with the term clean code then this should be a no-brainer.
Put simply, clean code is well-written code.
By that I mean: easy to read and understand; easy to change; and it contains only what is essential to run the application (for example, no dead code).
So what are we cleaning exactly?
In this step, we want to clean the Webpack configuration. This is the file that defines Webpack’s custom behavior and functionality. Often developers apply clean code principles to their code base. There is no reason why this thinking should not be extended to your Webpack configuration.
The key takeaways here are three-fold:
- Get rid of any unused dependencies … now! I appreciate that this does not make your webpack bundle smaller (as webpack only bundles libraries that are used) but this is more in the interests of maintaining the sanity of any developer that works on the code base in the future. To find out what dependencies are no longer used, I recommend taking a look at the DepCheck library.
- Upgrade any remaining dependencies where you can. On the particular project I worked on, some of the dependencies were more than 4 major versions behind. Among the obvious benefits, like better reliability and security, sometimes more recent versions will have optimizations that result in less code.
- Finally, it's worth doing a review of your webpack configuration to see if this can be cleaned up further. If you have one large webpack configuration for all environments (dev and prod), then consider splitting it. Check out the example I uploaded to Github.
So, by now you have a nice readable Webpack configuration, and you have upgraded your dependencies and removed any ones that are no longer required. The next step is to analyze your bundle to see what is taking up the most space.
A simple visual tool for examining your bundle is the Webpack Visualizer. It provides a nice looking pie chart of your bundle composition allowing you to quickly understand which dependencies contribute to the size of the overall result.
For the less visual, and for other useful, alternatives take a look at Survive JS.
Once you have a picture of your dependencies and their weight, then start thinking about which ones are really required.
Now that you are only using the dependencies that are absolutely essential, the next step is to reduce their weight further by adding a couple of plugins to your Webpack configuration.
The Dedupe plugin searches for equal or similar files and de-duplicates them in the output.
The Uglify plugin minifies your code. Be aware that this can end up making it pretty unreadable when debugging in your browser's dev tools. Adding source maps provides a way to convert it back to the original source code.
The above plugins are just two of many that can help reduce the weight of your code. There are also minimizers for CSS files and it's worth checking out this option if it applies.
Finally, if you a lucky enough to be using a Content Delivery Network (CDN), then it may be worth considering externalizing any large remaining dependencies (for example, ReactJS, jQuery, Moment, etc.).
Rather than installing and providing a large library like jQuery locally, you instead serve it on your CDN, link to it, and declare this relationship in your Webpack configuration. This can significantly reduce your bundle size.
But at this point, you may be scratching your head.
You may be thinking, 'If I make a dependency external doesn’t this just move the dependency (and the loading problem) elsewhere?'
Yes. But there is an additional advantage.
Browsers have the ability to load files in parallel. So rather than require the browser to load one big bundle, you can get some further optimization by allowing the browser to download two smaller files in parallel. The CDN also provides caching benefits, so it enables faster loads on subsequent visits.
The End Result
Once you have applied the steps above and build your application (don’t forget to run the -p parameter), hopefully, you should now see some big differences in the build output in your terminal. It was through this process that our team was able to reduce the size of five application bundles from the 2mb mark down to around 300kb, making the internet a happier and safer place for all.
Published at DZone with permission of Toby Retallick, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.