#8 Step By Step: Bundle Analyzer Plugin

What do our bundles look like?

npm install --save-dev webpack-bundle-analyzer

{
    ...,
    "devDependencies": {
        ...,
        "webpack-bundle-analyzer": "^2.13.1",
        ...
    }
}

Of course for us to make use of our newly installed package we need to modify our webpack configuration by adding it to our plugins array (c). As in previous articles we are pushing the plugin into our array instead of just including it in the initialization because we are going to modify how it is added in just a little bit.

...
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
...
plugins.push(new BundleAnalyzerPlugin());
...

Now that the plugin is added if we run our npm run build command again once our bundle is built a browser window should be open automatically that shows something very similar to what is shown in (d). The diagram that is shown is called a Voronoi diagram and if you hover our mouse of a cell you get information about the size of the contents of that particular cell.

(d) A Voronoi diagram of the contents of our bundle.

The reason that we have so much code included within our bundle when all we really have for our application is a console statement is because we are analyzing a bundle which contains all the front end code needed to make hot module replacement work. We do not really care about all of this extra code. All we are concerned about is the amount of code that will be shipped to our end users. Our next step is to change when we add in the analyzer plugin.

Production size is all that matters

{
    ...
    "scripts": {
        ...,
        "build:prod": "set NODE_ENV=production&&webpack --progress -p",
        ...
    },
    ...
}

Now that we can specify a build as a production build we can modify our webpack configuration to only include the analyzer plugin when we do so (f).

...
const isProd = mode === "production";
...
if (isProd) {
    plugins.push(new BundleAnalyzerPlugin());
}
...

With that done if we use the npm run build:prod command we should now see the diagram of our bundle look something like (g).

(g) The diagram of our bundle no longer contains the code for hot module replacement.

Now we could just stop here since everything is working as it should be but over time it does get a bit annoying that whenever we create a production bundle a server instance is started that we need to kill and a browser window is open that we need to close. Let's fix this.

Only analyze when I say to

{
    ...
    "scripts": {
        ...,
        "build:analyze": "set NODE_ENV=production&&set BUNDLE_ANALYZE=true&&webpack --progress -p",
        ...
    },
    ...
}

Now instead of checking whether the bundle we are creating is a production bundle we will check to see if our BUNDLE_ANALYZE variable has been set (i).

...
const isAnalyze = typeof process.env.BUNDLE_ANALYZE !== "undefined";
...
if (isAnalyze) {
    plugins.push(new BundleAnalyzerPlugin());
}
...

We are now ready and able to analyze the size and contents of our bundles to see if there are areas that we may be able to realize some savings by reducing and or eliminating things that we do not need.

How about an example

We start by saying we would like to include some font awesome icons in our project and installing the needed packages from npm (j).

npm install --save-dev
@fortawesome/fontawesome-svg-core
@fortawesome/free-solid-svg-icons

For the overall purpose of this example the version numbers do not really matter but for completeness they are shown in (k).

{
    ...
    "devDependencies": {
        "@fortawesome/fontawesome-svg-core": "^1.2.2",
        "@fortawesome/free-solid-svg-icons": "^5.2.0",
        ...
    }
}

Does our project support tree shaking?

import { library } from "@fortawesome/fontawesome-svg-core";
import { faAddressBook } from "@fortawesome/free-solid-svg-icons";

library.add(faAddressBook);

import { library } from "@fortawesome/fontawesome-svg-core";
import { faAddressBook } from "@fortawesome/free-solid-svg-icons/faAddressBook";

library.add(faAddressBook);

We of course need to modify our entry object to point to the two files that we just created (n).

...
const entry = {
    "index-fa-all": "./Source/index-fa-all.ts",
    "index-fa-single": "./Source/index-fa-single.ts"
}
...

With that all done if we now analyze the size of our bundles we will see a huge discrepancy between the two in terms of their overall size (o).

(o) Depending on how your project is setup your bundles may not be created the way you think they are being created.

The point of this is that you can use this particular example to help with your particular project but to show how using the bundle analyzer plugin we may be able to pin point an opportunity or two tow reduce the size of the bundles that are shipped to the end user.