build performance

WIP

Incremental builds

Make sure you don't do a full rebuild. webpack has a great caching layer that allows to keep already compiled modules in memory. There are some tools that help to use it:

• webpack-dev-server: Serves all webpack assets from memory. Best performance.
• webpack-dev-middleware: The same as middleware for advanced users.
• webpack --watch or [[watch: true | node.js API]]: Caches stuff but write assets to disk. Ok performance.

Prefetching modules

[[prefetch | http://webpack.github.io/docs/list-of-plugins.html#prefetchplugin]]

Exclude modules from parsing

With [[noParse | http://webpack.github.io/docs/configuration.html#module-noparse]] you can exclude big libraries from parsing, but this can break stuff.

Hints from build stats

There is an analyse tool which visualise your build and also provides some hint how build size and build performance can be optimized.

You can generate the required JSON file by running webpack --profile --json > stats.json

SourceMaps

Perfect SourceMaps are slow.

devtool: "source-map" cannot cache SourceMaps for modules and need to regenerate complete SourceMap for the chunk. It's something for production...

devtool: "eval-source-map" is really as good as devtool: "source-map", but can cache SourceMaps for modules. It's much faster for rebuilds.

devtool: "eval-cheap-module-source-map" offers SourceMaps that only maps lines (no column mappings) and are much faster.

devtool: "eval-cheap-source-map" is similar but doesn't generate SourceMaps for modules (i. e. jsx to js mappings).

The best performance has devtool: "eval", but it only maps to compiled source code per module. In many cases this is good enough. Hint: combine it with output.pathinfo: true.

The UglifyJsPlugin uses SourceMaps to map errors to source code. And SourceMaps are slow. As you should only use this in production this is fine. If your production build is really slow (or doesn't finish at all) you can disable it with new UglifyJsPlugin({ sourceMap: false }).