Posted in Uncategorized

Webpack 2: Larger Bundle Size in Stats Analysis Tool

   February 23, 2021  3 Comments on Webpack 2: Larger Bundle Size in Stats Analysis Tool

I was excited for Webpack 2 and Tree Shaking but upon implementing it into my application is seems to bloat the bundle by about 300kb. I can try to reproduce this in a smaller sample repo but for now I’ll just show screenshots of my current application bundle size from generated stats. Here is a link to my generated stats and below are screenshots:

https://drive.google.com/folderview?id=0Bz7gMzxYFJb9cVc1dUdBZlpvZVE&usp=sharing

Webpack 1

webpack-1-stats-screen-shot

##### Webpack 2

webpack-2-stats-screen-shot

  const babelrc = `{
    "presets": ["react", "es2015-webpack", "stage-0"],
    "env": {
      "development": {
        "plugins": [
          "rewire",
          "transform-decorators-legacy",
          "typecheck",
          ["transform-runtime", {"polyfill": true}],
          ["react-transform",
            {
            "transforms": [{
              "transform": "react-transform-hmr",
              "imports": ["react"],
              "locals": ["module"]
            }, {
              "transform": "react-transform-catch-errors",
              "imports": ["react", "redbox-react"]
            }]
          }]
        ]
      },
      "production": {
        "plugins": [
          ["transform-runtime", {"polyfill": true}],
          "transform-decorators-legacy",
          "typecheck"
        ]
      }
    }
  }`;

Author: Fantashit

3 thoughts on “Webpack 2: Larger Bundle Size in Stats Analysis Tool”

  1. I am experiencing the same. Was equally excited by the treeshaking features, knowing that I use precious little of libraries such as ramda, but after the upgrade the resultant build was almost equivalent of my previous build size. UglifyJs and the new LoaderOptions plugins were both being used.

  2. Experiencing the same thing here with a big Angular app.

    Our code isn’t written in a way that would benefit much from tree-shaking, but it appears that Webpack’s native ES6 module support always produces code that is considerably more verbose than Babel’s CJS transpiler.

    If I use Babel to transpile my ES6 modules into CJS, Webpack 2’s performance isn’t quite as bad (but is still worse than Webpack 1.13.0).

    The following simple script demonstrates my case nicely:

    import angular from 'angular';
import moment from 'moment';

export default angular.module('foo', [])
.run(function(){
    window.foo = moment();
});

    Using Webpack to “bundle” the above script (with the CommonsChunkPlugin splitting Angular & Moment into a separate chunk), the Webpack 2 consistently produces a larger bundle:

    Webpack Version Babel Preset Unminified Size Minified Size Unminified vendor.js Minified vendor.js
    Webpack 2.1.0-beta.6 babel-preset-es2015 595B 284B 1.65MB 358kB
    Webpack 2.1.0-beta.6 babel-preset-es2015-webpack 1.44kB 360B 1.65MB 358kB
    Webpack 1.13.0 babel-preset-es2015 584B 274B 1.32MB 214kB

    Here’s the webpack.config.js used for the above comparison. (The modifications I made between runs should be obvious from the description)

    Webpack 2’s ES6 transpilation appears to be adding some overhead to the test script above, and is slightly less efficient even when Babel does the CJS transformation for me. Somewhat surprisingly, the Angular/Moment bundle gets significantly larger when Bundled with Webpack 2.

    If you click through on the above file sizes, you can see just how much more verbose Webpack 2’s output can be. It seems like there are some relatively straightforward opportunities to make this more efficient for most common/simple cases…

  3. Another question that’s surfaced while examining this issue:

    Why doesn’t Webpack “inline” modules that are only used once? A lot of rollup’s advantages are derived from the fact that it does this…

    Even if we only did this in simple cases (ie. a module that exports a string and nothing else), it seems like we could shave a few bytes off of most typical bundles.

Comments are closed.