It’s crucial for development teams to keep their bundle size and build time in check. This not only improves the developer experience for you and your team but also your user’s experience. If you’re using Webpack for bundling, there are a couple quick things you can check on to improve your build time and bundle size.
Check your source maps.
One easy step to improve your Webpack bundling is to check which configuration you’re using to provide source maps with your bundle. This is configured using the “devtool” option in your Webpack config (see the spec here).
First, I’ll assume you’re using separate bundles for development and production (i.e. you have two separate Webpack configs with one having a “development” mode and the other having a “production” mode). If you don’t, you might want to think about implementing separate dev and prod bundles. Otherwise, you can’t reap the benefits of optimizing bundling for separate environments (including the following).
Now that this step is out of the way, it’s important to decide if you want to use source maps in your production bundle. And, if you don’t want them, make sure they’re turned off (i.e. the “devtool” option is completely omitted from your prod config). Source maps are mostly for developer use, and they could take up a large part of your bundle size. That means you’ll most likely want to turn them off in prod. If there’s a situation where you want to use source maps in production, make sure to use a devtool configuration that works best with a prod bundle (refer to the “production” column in the spec).
Furthermore, if you’re looking to improve the build time on your local development builds, double check which source map configuration you’re using in your dev config. If you’re using a configuration like “inline-source-map,” consider switching to a config with a faster build time, like “eval-cheap-source-map.” This configuration includes line number mappings but leaves out column number mappings. This can be a good tradeoff to make for an increase in build time. You can check each configuration’s details, as well as how fast they build, in the devtool spec.
Optimize your imports.
It’s very possible you could be importing more of your packages into your code than you need to. Some packages will allow you to import the specific files or modules you need, rather than the whole package. This leaves out unused code and can really cut down your bundle size.
A commonly-used package that can be optimized this way is Lodash. If you’re using Lodash in your code, and importing from it like this:
import _ from "lodash";
or this:
import { flattenDeep, map, max, min } from "lodash";
…you’re actually including the entire package in your bundle, which ends up being ~72.5 kB. This can turn out to be a pretty big chunk of your app when it comes to bundle sizes.
However, lodash serves its functions from individual files as well. If you imported each function separately, like this:
import flattenDeep from "lodash/flattenDeep"; import map from "lodash/map"; import max from "lodash/max"; import min from "lodash/min";
…only the files needed for those functions are imported from the package. This reduces the Lodash chunk of your bundle to about ~10-20 kB. Much better! You can check out this blog post for more details on optimizing your lodash imports.
Like Lodash, many other packages allow you to import only the specific file or module you need. Optimizing these imports in your code could exponentially reduce your bundle size. Some packages may even offer purely modular versions (Lodash, for example, has lodash-es), which can allow Webpack to use minification with tree shaking to automatically trim out code that isn’t being touched. (If you’re using Webpack 4+, minification is enabled by default in production mode https://webpack.js.org/guides/production/#minification.)
Improve Your Webpack Bundling
Taking a glance over your source map configurations and package imports are two quick things you can do to reduce your bundle size and build time. Think about how much time you spend building your code, or how much time your users spend loading your web application, in a day, a month, or a year. All this time can easily add up, and every little bit can go a long way.