Your Bundle Size impacts your Users

Most web developers know that the HTTP calls associated with pulling down javascript files are blocking. Quite a few of us have also made the switch to Webpack or Rollup solutions to implementing ES6 modules. These create bundles of our applications.

The resulting bundle can be extremely large. This is especially true if styles, images, fonts, etc are all built into your bundle. As your bundle bloats, your initial load time does, as well. This results in a bad user experience, as the user will be left with a blank screen until your bundle finishes loading.

There are several things made available to you to utilize to fix this problem. Webpack is where my expertise lies, and I will focus on those solutions.

Bundle Chunking

Bundle chunking is the act of splitting your code apart. The nice part of this, is webpack has several ways of doing this. If your files are not dependent on other parts of the app, and vice versa, a second entry point can be made, for instance.

Also, there is a plugin called the CommonsChunkPlugin, which identifies shared dependency modules in your dependencies, and pulls them into a single chunk. This is a very powerful plugin, as it allows you to load your most critical dependencies first, and then add onto the app with other chunks.

Your CSS

While it’s convenient to use an import statement to load your CSS into the application, it’s not necessary. On top of that, it’s detrimental to your bundle size and the user’s experience. Again, webpack offers a solution to this problem. You can still utilize the import statement in your javascript, but use the [Extract Text](https://github.com/webpack-contrib/extract-text-webpack-plugin) webpack plugin. This allows you to define which rules in your webpack build process should be extracted from the bundle and another chunk created.

This can save several megabytes of bundle, especially if a preprocessor such as SASS is used.

The biggest benefit to splitting out your CSS, is that, if it loads before your bundle finishes, you can have a default element in the index page that has a loading indicator. At a minimum, this will give your user a better experience because they are no longer wondering if the app is even working, as they now have an indication that something is happening.

Eliminating Dependencies

This is probably harder to do. There are many libraries we all depend on to make development easier. Think moment, lodash, ramda and the like. There is obviously a limit to the amount of dependencies that can be removed. But are you using lodash and ramda in the same project? Can you perform the same functionality with one or the other? If so, your bundle can benefit by eliminating the fluff.

In addition, there are other things to consider. Moment, for instance, pulls in dozens of locales by default. This is extremely beneficial to applications that are internationalized. However, the library is insanely useful to developers, even if their application isn’t internationalized.
Webpack offers a solution to this problem with the [ignore plugin](https://webpack.github.io/docs/list-of-plugins.html#ignoreplugin). You can specify which context should be ignored by the webpack build process.

Conclusion

In conclusion, while bundling has given us a lot of power to write beautiful, modular code, we need to be aware of the problems associated with it. If your bundle is getting large, it will impact your user’s experience. If your site is intended to be accessed by mobile, this impact could cost business, as people typically don’t have the patience to wait for a page to load.

Utilizing the above described approaches to bundle chunking, you should be able to limit the impact of bundling, and your user will benefit as a result!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.