Webpack

At first glance

Know what you have in your pocket.

User webpack -json > tree.json to get all the information about your modules.
For visualization, put the tree.json to this https://webpack.github.io/analyse/#home
To parse those information to human-readable code, use this package https://github.com/robertknight/webpack-bundle-size-analyzer with its command webpack --json | webpack-bundle-size-analyzer

Minimize

To minimize your scripts (and your css, if you use the css-loader) webpack supports a simple option:

--optimize-minimize resp. new webpack.optimize.UglifyJsPlugin()

That’s a simple but effective way to optimize your web app.

As you already know (if you’ve read the remaining docs) webpack gives your modules and chunks ids to identify them. Webpack can vary the distribution of the ids to get the smallest id length for often used ids with a simple option:

--optimize-occurrence-order resp. new webpack.optimize.OccurrenceOrderPlugin()

The entry chunks have higher priority for file size.

Build with PRODUCTION flag

We simply created NODE_ENV with the value is production

plugins: [
  new webpack.DefinePlugin({
    'process.env': {
      'NODE_ENV': JSON.stringify('production')
    }
  })
]

Source Maps

It’s common to see devtool: ‘eval’ which is one of the fastest ways to build apps with most of the development code information bundled in the output. While that’s really nice for development purposes, we will want to get rid of any unnecessary data in a production build. There are a few production-ready options to go with, and we’ll go with cheap-module-source-map (instead of eval) to minimize the output.

Deduplication

If you use some libraries with cool dependency trees, it may occur that some files are identical. Webpack can find these files and deduplicate them. This prevents the inclusion of duplicate code into your bundle and instead applies a copy of the function at runtime. It doesn’t affect semantics. You can enable it with:

--optimize-dedupe resp. new webpack.optimize.DedupePlugin()

This feature adds some overhead to the entry chunk.

Chunks

While writing your code, you may have already added many code split points to load stuff on demand. After compiling you might notice that there are too many chunks that are too small - creating larger HTTP overhead. Luckily, Webpack can post-process your chunks by merging them. You can provide two options:

Limit the maximum chunk count with --optimize-max-chunks 15 new webpack.optimize.LimitChunkCountPlugin({maxChunks: 15})
Limit the minimum chunk size with --optimize-min-chunk-size 10000 new webpack.optimize.MinChunkSizePlugin({minChunkSize: 10000})

Webpack will take care of it by merging chunks (it will prefer merging chunk that have duplicate modules). Nothing will be merged into the entry chunk, so as not to impact initial page loading time.

Probably also worth mentioning the Babel optimizations React apps in production: React inline elements transform · Babel

The compiler for writing next generation JavaScript babeljs.io React constant elements transformer · Babel

The compiler for writing next generation JavaScript babeljs.io

Babel optimization for React

Probably also worth mentioning the Babel optimizations React apps in production:
React inline elements transform · Babel
https://babeljs.io/docs/plugins/transform-react-inline-elements/

React constant elements transformer · Babel
https://babeljs.io/docs/plugins/transform-react-constant-elements/

Optimize lodash lib

You will only have in your the webpack bundle what you've imported

Transforms

import _ from 'lodash';
import { add } from 'lodash/fp';
 
let add1 = add(1);
_.map([1, 2, 3], add1);

roughly to

import _add from 'lodash/fp/add';
import _map from 'lodash/map';
 
let add1 = _add(1);
_map([1, 2, 3], add1);

More details https://www.npmjs.com/package/babel-plugin-lodash

khanghoang/optimization-webpack.md