Ivan Akulov on web.dev

Webpack conclusion

2018-02-08T00:00:00Z

Summing up:

Cut unnecessary bytes. Compress everything, strip unused code, be wise when adding dependencies
Split code by routes. Load only what’s really necessary right now and lazy-load other stuff later
Cache code. Some parts of your app are updated less often than other ones. Separate these parts into files so that they are only re-downloaded when necessary
Keep track of the size. Use tools like webpack-dashboard and webpack-bundle-analyzer to stay aware how large is your app. Take a fresh look at your app’s performance at whole every few months

Webpack is not the only tool that could help you make an app faster. Consider making your application a Progressive Web App for even better experience and use automated profiling tools like Lighthouse to get improvement suggestions.

Don’t forget to read webpack docs – they have plenty of other useful information.

And make sure to play with the training app!

Make use of long-term caching

2018-02-08T00:00:00Z

The next thing (after optimizing the app size that improves the app loading time is caching. Use it to keep parts of the app on the client and avoid re-downloading them every time.

Use bundle versioning and cache headers #

The common approach of doing caching is to:

tell the browser to cache a file for a very long time (e.g., a year):
```
# Server header
Cache-Control: max-age=31536000
```
If you aren't familiar what Cache-Control does, see Jake Archibald's excellent post on caching best practices.

and rename the file when it's changed to force the re-download:

<!-- Before the change -->
<script src="./index-v15.js"></script>

<!-- After the change -->
<script src="./index-v16.js"></script>

This approach tells the browser to download the JS file, cache it and use the cached copy. The browser will only hit the network only if the file name changes (or if a year passes).

With webpack, you do the same, but instead of a version number, you specify the file hash. To include the hash into the file name, use [chunkhash]:

// webpack.config.js
module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.[chunkhash].js' // → bundle.8e0d62a03.js
  }
};

If you need the file name to send it to the client, use either the HtmlWebpackPlugin or the WebpackManifestPlugin.

The HtmlWebpackPlugin is a simple, but less flexible approach. During compilation, this plugin generates an HTML file which includes all compiled resources. If your server logic isn't complex, then it should be enough for you:

<!-- index.html -->
<!DOCTYPE html>
<!-- ... -->
<script src="bundle.8e0d62a03.js"></script>

The WebpackManifestPlugin is a more flexible approach which is useful if you have a complex server part. During the build, it generates a JSON file with a mapping between file names without hash and file names with hash. Use this JSON on the server to find out which file to work with:

// manifest.json
{
  "bundle.js": "bundle.8e0d62a03.js"
}

Extract dependencies and runtime into a separate file #

Dependencies #

App dependencies tend to change less often than the actual app code. If you move them into a separate file, the browser will be able to cache them separately – and won't re-download them each time the app code changes.

Key Term: In webpack terminology, separate files with the app code are called chunks. We'll use this name later.

To extract dependencies into a separate chunk, perform three steps:

Replace the output filename with [name].[chunkname].js:
```
// webpack.config.js
module.exports = {
  output: {
    // Before
    filename: 'bundle.[chunkhash].js',
    // After
    filename: '[name].[chunkhash].js'
  }
};
```
When webpack builds the app, it replaces [name] with a name of a chunk. If we don't add the [name] part, we'll have to differentiate between chunks by their hash – which is pretty hard!
Convert the entry field into an object:
```
// webpack.config.js
module.exports = {
  // Before
  entry: './index.js',
  // After
  entry: {
    main: './index.js'
  }
};
```
In this snippet, "main" is a name of a chunk. This name will be substituted in place of [name] from step 1.

By now, if you build the app, this chunk will include the whole app code – just like we haven't done these steps. But this will change in a sec.

In webpack 4, add the optimization.splitChunks.chunks: 'all' option into your webpack config:

// webpack.config.js (for webpack 4)
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all'
    }
  }
};

This option enables smart code splitting. With it, webpack would extract the vendor code if it gets larger than 30 kB (before minification and gzip). It would also extract the common code – this is useful if your build produces several bundles (e.g. if you split your app into routes).

In webpack 3, add the CommonsChunkPlugin:

// webpack.config.js (for webpack 3)
module.exports = {
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
    // A name of the chunk that will include the dependencies.
    // This name is substituted in place of [name] from step 1
    name: 'vendor',

    // A function that determines which modules to include into this chunk
    minChunks: module => module.context && module.context.includes('node_modules'),
    })
  ]
};

This plugin takes all modules which paths include node_modules and moves them into a separate file called vendor.[chunkhash].js.

After these changes, each build will generate two files instead of one: main.[chunkhash].js and vendor.[chunkhash].js (vendors~main.[chunkhash].js for webpack 4). In case of webpack 4, the vendor bundle might not be generated if dependencies are small – and that's fine:

$ webpack
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
                        Asset      Size  Chunks             Chunk Names
 ./main.00bab6fd3100008a42b0.js   82 kB       0  [emitted]  main
./vendor.d9e134771799ecdf9483.js  47 kB       1  [emitted]  vendor

The browser would cache these files separately – and redownload only code that changes.

Webpack runtime code #

Unfortunately, extracting just the vendor code is not enough. If you try to change something in the app code:

// index.js
…
…

// E.g. add this:
console.log('Wat');

you'll notice that the vendor hash also changes:

                           Asset   Size  Chunks             Chunk Names
./vendor.d9e134771799ecdf9483.js  47 kB       1  [emitted]  vendor

↓

                            Asset   Size  Chunks             Chunk Names
./vendor.e6ea4504d61a1cc1c60b.js  47 kB       1  [emitted]  vendor

This happens because the webpack bundle, apart from the code of modules, has a runtime – a small piece of code that manages the module execution. When you split the code into multiple files, this piece of code starts including a mapping between chunk ids and corresponding files:

// vendor.e6ea4504d61a1cc1c60b.js
script.src = __webpack_require__.p + chunkId + "." + {
    "0": "2f2269c7f0a55a5c1871"
}[chunkId] + ".js";

Webpack includes this runtime into the last generated chunk, which is vendor in our case. And every time any chunk changes, this piece of code changes too, causing the whole vendor chunk to change.

To solve this, let's move the runtime into a separate file. In webpack 4, this is achieved by enabling the optimization.runtimeChunk option:

// webpack.config.js (for webpack 4)
module.exports = {
  optimization: {
    runtimeChunk: true
  }
};

In webpack 3, do this by creating an extra empty chunk with the CommonsChunkPlugin:

// webpack.config.js (for webpack 3)
module.exports = {
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: module => module.context && module.context.includes('node_modules')
    }),
    // This plugin must come after the vendor one (because webpack
    // includes runtime into the last chunk)
    new webpack.optimize.CommonsChunkPlugin({
      name: 'runtime',
      // minChunks: Infinity means that no app modules
      // will be included into this chunk
      minChunks: Infinity
    })
  ]
};

After these changes, each build will be generating three files:

$ webpack
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
                            Asset     Size  Chunks             Chunk Names
   ./main.00bab6fd3100008a42b0.js    82 kB       0  [emitted]  main
 ./vendor.26886caf15818fa82dfa.js    46 kB       1  [emitted]  vendor
./runtime.79f17c27b335abc7aaf4.js  1.45 kB       3  [emitted]  runtime

Include them into index.html in the reverse order – and you're done:

<!-- index.html -->
<script src="./runtime.79f17c27b335abc7aaf4.js"></script>
<script src="./vendor.26886caf15818fa82dfa.js"></script>
<script src="./main.00bab6fd3100008a42b0.js"></script>

Inline webpack runtime to save an extra HTTP request #

To make things even better, try inlining the webpack runtime into the HTML response. I.e., instead of this:

<!-- index.html -->
<script src="./runtime.79f17c27b335abc7aaf4.js"></script>

do this:

<!-- index.html -->
<script>
!function(e){function n(r){if(t[r])return t[r].exports;…}} ([]);
</script>

The runtime is small, and inlining it will help you save an HTTP request (pretty important with HTTP/1; less important with HTTP/2 but might still play an effect).

Here's how to do it.

If you generate HTML with the HtmlWebpackPlugin #

If you use the HtmlWebpackPlugin to generate an HTML file, the InlineSourcePlugin is all you need:

const HtmlWebpackPlugin = require('html-webpack-plugin');
const InlineSourcePlugin = require('html-webpack-inline-source-plugin');

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
      inlineSource: 'runtime~.+\\.js',
    }),
    new InlineSourcePlugin()
  ]
};

If you generate HTML using a custom server logic #

With webpack 4:

Add the WebpackManifestPlugin to know the generated name of the runtime chunk:

// webpack.config.js (for webpack 4)
const ManifestPlugin = require('webpack-manifest-plugin');

module.exports = {
  plugins: [
    new ManifestPlugin()
  ]
};

A build with this plugin would create a file that looks like this:

// manifest.json
{
  "runtime~main.js": "runtime~main.8e0d62a03.js"
}

Inline the content of the runtime chunk in a convenient way. E.g. with Node.js and Express:

// server.js
const fs = require('fs');
const manifest = require('./manifest.json');
const runtimeContent = fs.readFileSync(manifest['runtime~main.js'], 'utf-8');

app.get('/', (req, res) => {
  res.send(`
    …
    <script>${runtimeContent}</script>
    …
  `);
});

Or with webpack 3:

Make the runtime name static by specifying filename:

module.exports = {
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'runtime',
      minChunks: Infinity,
      filename: 'runtime.js'
    })
  ]
};

Inline the runtime.js content in a convenient way. E.g. with Node.js and Express:

// server.js
const fs = require('fs');
const runtimeContent = fs.readFileSync('./runtime.js', 'utf-8');

app.get('/', (req, res) => {
  res.send(`
    …
    <script>${runtimeContent}</script>
    …
  `);
});

Lazy-load code that you don't need right now #

Sometimes, a page has more and less important parts:

If you load a video page on YouTube, you care more about the video than about comments. Here, the video is more important than comments.
If you open an article on a news site, you care more about the text of the article than about ads. Here, the text is more important than ads.

In such cases, improve the initial loading performance by downloading only the most important stuff first, and lazy loading the remaining parts later. Use the import() function and code-splitting for this:

// videoPlayer.js
export function renderVideoPlayer() { … }

// comments.js
export function renderComments() { … }

// index.js
import {renderVideoPlayer} from './videoPlayer';
renderVideoPlayer();

// …Custom event listener
onShowCommentsClick(() => {
  import('./comments').then((comments) => {
    comments.renderComments();
  });
});

import() specifies that you want to load a specific module dynamically. When webpack sees import('./module.js'), it moves this module into a separate chunk:

$ webpack
Hash: 39b2a53cb4e73f0dc5b2
Version: webpack 3.8.1
Time: 4273ms
                            Asset     Size  Chunks             Chunk Names
      ./0.8ecaf182f5c85b7a8199.js  22.5 kB       0  [emitted]
   ./main.f7e53d8e13e9a2745d6d.js    60 kB       1  [emitted]  main
 ./vendor.4f14b6326a80f4752a98.js    46 kB       2  [emitted]  vendor
./runtime.79f17c27b335abc7aaf4.js  1.45 kB       3  [emitted]  runtime

and downloads it only when execution reaches the import() function.

This will make the main bundle smaller, improving the initial loading time. Even more, it will improve caching – if you change the code in the main chunk, comments chunk won't get affected.

Split the code into routes and pages #

If your app has multiple routes or pages, but there's only a single JS file with the code (a single main chunk), it's likely that you're serving extra bytes on each request. For example, when a user visits a home page of your site:

they don't need to load the code for rendering an article that's on a different page – but they will load it. Moreover, if the user always visits only the home page, and you make a change in the article code, webpack will invalidate the whole bundle – and the user will have to re-download the whole app.

If we split the app into pages (or routes, if it's a single-page app), the user will download only the relevant code. Plus, the browser will cache the app code better: if you change the home page code, webpack will invalidate only the corresponding chunk.

For single-page apps #

To split single-page apps by routes, use import() (see the “Lazy-load code that you don't need right now” section). If you use a framework, it might have an existing solution for this:

"Code Splitting" in react-router's docs (for React)
"Lazy Loading Routes" in vue-router's docs (for Vue.js)

For traditional multi-page apps #

To split traditional apps by pages, use webpack's entry points. If your app has three kinds of pages: the home page, the article page and the user account page, – it should have three entries:

// webpack.config.js
module.exports = {
  entry: {
    home: './src/Home/index.js',
    article: './src/Article/index.js',
    profile: './src/Profile/index.js'
  }
};

For each entry file, webpack will build a separate dependency tree and generate a bundle that includes only modules that are used by that entry:

$ webpack
Hash: 318d7b8490a7382bf23b
Version: webpack 3.8.1
Time: 4273ms
                            Asset     Size  Chunks             Chunk Names
      ./0.8ecaf182f5c85b7a8199.js  22.5 kB       0  [emitted]
   ./home.91b9ed27366fe7e33d6a.js    18 kB       1  [emitted]  home
./article.87a128755b16ac3294fd.js    32 kB       2  [emitted]  article
./profile.de945dc02685f6166781.js    24 kB       3  [emitted]  profile
 ./vendor.4f14b6326a80f4752a98.js    46 kB       4  [emitted]  vendor
./runtime.318d7b8490a7382bf23b.js  1.45 kB       5  [emitted]  runtime

So, if only the article page uses Lodash, the home and the profile bundles won't include it – and the user won't have to download this library when visiting the home page.

Separate dependency trees have their drawbacks though. If two entry points use Lodash, and you haven't moved your dependencies into a vendor bundle, both entry points will include a copy of Lodash. To solve this, in webpack 4, add the optimization.splitChunks.chunks: 'all' option into your webpack config:

// webpack.config.js (for webpack 4)
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all'
    }
  }
};

This option enables smart code splitting. With this option, webpack would automatically look for common code and extract it into separate files.

Or, in webpack 3, use the CommonsChunkPlugin – it will move common dependencies into a new specified file:

module.exports = {
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'common',
      minChunks: 2    // 2 is the default value
    })
  ]
};

Feel free to play with the minChunks value to find the best one. Generally, you want to keep it small, but increase if the number of chunks grows. For example, for 3 chunks, minChunks might be 2, but for 30 chunks, it might be 8 – because if you keep it at 2, too many modules will get into the common file, inflating it too much.

Make module ids more stable #

When building the code, webpack assigns each module an ID. Later, these IDs are used in require()s inside the bundle. You usually see IDs in the build output right before the module paths:

$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
                           Asset      Size  Chunks             Chunk Names
      ./0.8ecaf182f5c85b7a8199.js  22.5 kB       0  [emitted]
   ./main.4e50a16675574df6a9e9.js    60 kB       1  [emitted]  main
 ./vendor.26886caf15818fa82dfa.js    46 kB       2  [emitted]  vendor
./runtime.79f17c27b335abc7aaf4.js  1.45 kB       3  [emitted]  runtime

↓ Here

[0] ./index.js 29 kB {1} [built]
[2] (webpack)/buildin/global.js 488 bytes {2} [built]
[3] (webpack)/buildin/module.js 495 bytes {2} [built]
[4] ./comments.js 58 kB {0} [built]
[5] ./ads.js 74 kB {1} [built]
+ 1 hidden module

By default, IDs are calculated using a counter (i.e. the first module has ID 0, the second one has ID 1, and so on). The problem with this is that when you add a new module, it might appear in the middle of the module list, changing all the next modules' IDs:

$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
                           Asset      Size  Chunks             Chunk Names
      ./0.5c82c0f337fcb22672b5.js    22 kB       0  [emitted]
   ./main.0c8b617dfc40c2827ae3.js    82 kB       1  [emitted]  main
 ./vendor.26886caf15818fa82dfa.js    46 kB       2  [emitted]  vendor
./runtime.79f17c27b335abc7aaf4.js  1.45 kB       3  [emitted]  runtime
   [0] ./index.js 29 kB {1} [built]
   [2] (webpack)/buildin/global.js 488 bytes {2} [built]
   [3] (webpack)/buildin/module.js 495 bytes {2} [built]

↓ We've added a new module…

[4] ./webPlayer.js 24 kB {1} [built]

↓ And look what it has done! comments.js now has ID 5 instead of 4

[5] ./comments.js 58 kB {0} [built]

↓ ads.js now has ID 6 instead of 5

[6] ./ads.js 74 kB {1} [built]
       + 1 hidden module

This invalidates all chunks that include or depend on modules with changed IDs – even if their actual code hasn't changed. In our case, the 0 chunk (the chunk with comments.js) and the main chunk (the chunk with the other app code) get invalidated – whereas only the main one should've been.

To solve this, change how module IDs are calculated using the HashedModuleIdsPlugin. It replaces counter-based IDs with hashes of module paths:

$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
                           Asset      Size  Chunks             Chunk Names
      ./0.6168aaac8461862eab7a.js  22.5 kB       0  [emitted]
   ./main.a2e49a279552980e3b91.js    60 kB       1  [emitted]  main
 ./vendor.ff9f7ea865884e6a84c8.js    46 kB       2  [emitted]  vendor
./runtime.25f5d0204e4f77fa57a1.js  1.45 kB       3  [emitted]  runtime

↓ Here

[3IRH] ./index.js 29 kB {1} [built]
[DuR2] (webpack)/buildin/global.js 488 bytes {2} [built]
[JkW7] (webpack)/buildin/module.js 495 bytes {2} [built]
[LbCc] ./webPlayer.js 24 kB {1} [built]
[lebJ] ./comments.js 58 kB {0} [built]
[02Tr] ./ads.js 74 kB {1} [built]
    + 1 hidden module

With this approach, the ID of a module only changes if you rename or move that module. New modules won't affect other modules' IDs.

To enable the plugin, add it to the plugins section of the config:

// webpack.config.js
module.exports = {
  plugins: [
    new webpack.HashedModuleIdsPlugin()
  ]
};

Summing up #

Cache the bundle and differentiate between versions by changing the bundle name
Split the bundle into app code, vendor code and runtime
Inline the runtime to save an HTTP request
Lazy-load non-critical code with import
Split code by routes/pages to avoid loading unnecessary stuff

Decrease front-end size

2017-12-18T00:00:00Z

One of the first things to do when you’re optimizing an application is to make it as small as possible. Here’s how to do this with webpack.

Use the production mode (webpack 4 only) #

Webpack 4 introduced the new mode flag. You could set this flag to 'development' or 'production' to hint webpack that you’re building the application for a specific environment:

// webpack.config.js
module.exports = {
  mode: 'production',
};

Make sure to enable the production mode when you’re building your app for production. This will make webpack apply optimizations like minification, removal of development-only code in libraries, and more.

Enable minification #

Minification is when you compress the code by removing extra spaces, shortening variable names and so on. Like this:

// Original code
function map(array, iteratee) {
  let index = -1;
  const length = array == null ? 0 : array.length;
  const result = new Array(length);

  while (++index < length) {
    result[index] = iteratee(array[index], index, array);
  }
  return result;
}

↓

// Minified code
function map(n,r){let t=-1;for(const a=null==n?0:n.length,l=Array(a);++t<a;)l[t]=r(n[t],t,n);return l}

Webpack supports two ways to minify the code: the bundle-level minification and loader-specific options. They should be used simultaneously.

Bundle-level minification #

The bundle-level minification compresses the whole bundle after compilation. Here’s how it works:

You write code like this:

// comments.js
import './comments.css';
export function render(data, target) {
  console.log('Rendered!');
}

Webpack compiles it into approximately the following:

// bundle.js (part of)
"use strict";
Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
/* harmony export (immutable) */ __webpack_exports__["render"] = render;
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__comments_css__ = __webpack_require__(1);
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__comments_css_js___default =
__webpack_require__.n(__WEBPACK_IMPORTED_MODULE_0__comments_css__);

function render(data, target) {
console.log('Rendered!');
}

A minifier compresses it into approximately the following:

// minified bundle.js (part of)
"use strict";function t(e,n){console.log("Rendered!")}
Object.defineProperty(n,"__esModule",{value:!0}),n.render=t;var o=r(1);r.n(o)

In webpack 4, the bundle-level minification is enabled automatically – both in the production mode and without one. It uses the UglifyJS minifier under the hood. (If you ever need to disable minification, just use the development mode or pass false to the optimization.minimize option.)

In webpack 3, you need to use the UglifyJS plugin directly. The plugin comes bundled with webpack; to enable it, add it to the plugins section of the config:

// webpack.config.js
const webpack = require('webpack');

module.exports = {
  plugins: [
    new webpack.optimize.UglifyJsPlugin(),
  ],
};

Loader-specific options #

The second way to minify the code is loader-specific options (what a loader is). With loader options, you can compress things that the minifier can’t minify. For example, when you import a CSS file with css-loader, the file is compiled into a string:

/* comments.css */
.comment {
  color: black;
}

// minified bundle.js (part of)
exports=module.exports=__webpack_require__(1)(),
exports.push([module.i,".comment {\r\n  color: black;\r\n}",""]);

The minifier can’t compress this code because it’s a string. To minify the file content, we need to configure the loader to do this:

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          { loader: 'css-loader', options: { minimize: true } },
        ],
      },
    ],
  },
};

Specify `NODE_ENV=production` #

Another way to decrease the front-end size is to set the NODE_ENV environmental variable in your code to the value production.

Libraries read the NODE_ENV variable to detect in which mode they should work – in the development or the production one. Some libraries behave differently based on this variable. For example, when NODE_ENV is not set to production, Vue.js does additional checks and prints warnings:

// vue/dist/vue.runtime.esm.js
// …
if (process.env.NODE_ENV !== 'production') {
  warn('props must be strings when using array syntax.');
}
// …

React works similarly – it loads a development build that includes the warnings:

// react/index.js
if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

// react/cjs/react.development.js
// …
warning$3(
    componentClass.getDefaultProps.isReactClassApproved,
    'getDefaultProps is only used on classic React.createClass ' +
    'definitions. Use a static property named `defaultProps` instead.'
);
// …

Such checks and warnings are usually unnecessary in production, but they remain in the code and increase the library size. In webpack 4, remove them by adding the optimization.nodeEnv: 'production' option:

// webpack.config.js (for webpack 4)
module.exports = {
  optimization: {
    nodeEnv: 'production',
    minimize: true,
  },
};

In webpack 3, use the DefinePlugin instead:

// webpack.config.js (for webpack 3)
const webpack = require('webpack');

module.exports = {
  plugins: [
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"production"'
    }),
    new webpack.optimize.UglifyJsPlugin()
  ]
};

Both the optimization.nodeEnv option and the DefinePlugin work the same way – they replace all occurrences of process.env.NODE_ENV with the specified value. With the config from above:

Webpack will replace all occurrences of process.env.NODE_ENV with "production":

// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
  name = camelize(val);
  res[name] = { type: null };
} else if (process.env.NODE_ENV !== 'production') {
  warn('props must be strings when using array syntax.');
}

↓

// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
  name = camelize(val);
  res[name] = { type: null };
} else if ("production" !== 'production') {
  warn('props must be strings when using array syntax.');
}

And then the minifier will remove all such if branches – because "production" !== 'production' is always false, and the plugin understands that the code inside these branches will never execute:

// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
  name = camelize(val);
  res[name] = { type: null };
} else if ("production" !== 'production') {
  warn('props must be strings when using array syntax.');
}

↓

// vue/dist/vue.runtime.esm.js (without minification)
if (typeof val === 'string') {
  name = camelize(val);
  res[name] = { type: null };
}

Use ES modules #

The next way to decrease the front-end size is to use ES modules.

When you use ES modules, webpack becomes able to do tree-shaking. Tree-shaking is when a bundler traverses the whole dependency tree, checks what dependencies are used, and removes unused ones. So, if you use the ES module syntax, webpack can eliminate the unused code:

You write a file with multiple exports, but the app uses only one of them:

// comments.js
export const render = () => { return 'Rendered!'; };
export const commentRestEndpoint = '/rest/comments';

// index.js
import { render } from './comments.js';
render();

Webpack understands that commentRestEndpoint is not used and doesn’t generate a separate export point in the bundle:

// bundle.js (part that corresponds to comments.js)
(function(module, __webpack_exports__, __webpack_require__) {
"use strict";
const render = () => { return 'Rendered!'; };
/* harmony export (immutable) */ __webpack_exports__["a"] = render;

const commentRestEndpoint = '/rest/comments';
/* unused harmony export commentRestEndpoint */
})

The minifier removes the unused variable:

// bundle.js (part that corresponds to comments.js)
(function(n,e){"use strict";var r=function(){return"Rendered!"};e.b=r})

This works even with libraries if they are written with ES modules.

You aren’t required to use precisely webpack’s built-in minifier (UglifyJsPlugin) though. Any minifier that supports dead code removal (e.g. Babel Minify plugin or Google Closure Compiler plugin) will do the trick.

Optimize images #

Images account for more than a half of the page size. While they are not as critical as JavaScript (e.g., they don’t block rendering), they still eat a large part of the bandwidth. Use url-loader, svg-url-loader and image-webpack-loader to optimize them in webpack.

url-loader inlines small static files into the app. Without configuration, it takes a passed file, puts it next to the compiled bundle and returns an url of that file. However, if we specify the limit option, it will encode files smaller than this limit as a Base64 data url and return this url. This inlines the image into the JavaScript code and saves an HTTP request:

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.(jpe?g|png|gif)$/,
        loader: 'url-loader',
        options: {
          // Inline files smaller than 10 kB (10240 bytes)
          limit: 10 * 1024,
        },
      },
    ],
  }
};

// index.js
import imageUrl from './image.png';
// → If image.png is smaller than 10 kB, `imageUrl` will include
// the encoded image: 'data:image/png;base64,iVBORw0KGg…'
// → If image.png is larger than 10 kB, the loader will create a new file,
// and `imageUrl` will include its url: `/2fcd56a1920be.png`

svg-url-loader works just like url-loader – except that it encodes files with the URL encoding instead of the Base64 one. This is useful for SVG images – because SVG files are just a plain text, this encoding is more size-effective.

module.exports = {
  module: {
    rules: [
      {
        test: /\.svg$/,
        loader: "svg-url-loader",
        options: {
          limit: 10 * 1024,
          noquotes: true
        }
      }
    ]
  }
};

image-webpack-loader compresses images that go through it. It supports JPG, PNG, GIF and SVG images, so we’re going to use it for all these types.

This loader doesn’t embed images into the app, so it must work in pair with url-loader and svg-url-loader. To avoid copy-pasting it into both rules (one for JPG/PNG/GIF images, and another one for SVG ones), we’ll include this loader as a separate rule with enforce: 'pre':

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.(jpe?g|png|gif|svg)$/,
        loader: 'image-webpack-loader',
        // This will apply the loader before the other ones
        enforce: 'pre'
      }
    ]
  }
};

The default settings of the loader are already good to go – but if you want to configure it further, see the plugin options. To choose what options to specify, check out Addy Osmani’s excellent guide on image optimization.

Optimize dependencies #

More than a half of average JavaScript size comes from dependencies, and a part of that size might be just unnecessary.

For example, Lodash (as of v4.17.4) adds 72 KB of minified code to the bundle. But if you use only, like, 20 of its methods, then approximately 65 KB of minified code does just nothing.

Another example is Moment.js. Its 2.19.1 version takes 223 KB of minified code, which is huge – the average size of JavaScript on a page was 452 KB in October 2017. However, 170 KB of that size is localization files. If you don’t use Moment.js with multiple languages, these files will bloat the bundle without a purpose.

All these dependencies can be easily optimized. We’ve collected optimization approaches in a GitHub repo – check it out!

Enable module concatenation for ES modules (aka scope hoisting) #

When you are building a bundle, webpack is wrapping each module into a function:

// index.js
import {render} from './comments.js';
render();

// comments.js
export function render(data, target) {
  console.log('Rendered!');
}

↓

// bundle.js (part  of)
/* 0 */
(function(module, __webpack_exports__, __webpack_require__) {
  "use strict";
  Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
  var __WEBPACK_IMPORTED_MODULE_0__comments_js__ = __webpack_require__(1);
  Object(__WEBPACK_IMPORTED_MODULE_0__comments_js__["a" /* render */])();
}),
/* 1 */
(function(module, __webpack_exports__, __webpack_require__) {
  "use strict";
  __webpack_exports__["a"] = render;
  function render(data, target) {
    console.log('Rendered!');
  }
})

In the past, this was required to isolate CommonJS/AMD modules from each other. However, this added a size and performance overhead for each module.

Webpack 2 introduced support for ES modules which, unlike CommonJS and AMD modules, can be bundled without wrapping each with a function. And webpack 3 made such bundling possible – with module concatenation. Here’s what module concatenation does:

// index.js
import {render} from './comments.js';
render();

// comments.js
export function render(data, target) {
  console.log('Rendered!');
}

↓

// Unlike the previous snippet, this bundle has only one module
// which includes the code from both files

// bundle.js (part of; compiled with ModuleConcatenationPlugin)
/* 0 */
(function(module, __webpack_exports__, __webpack_require__) {
  "use strict";
  Object.defineProperty(__webpack_exports__, "__esModule", { value: true });

  // CONCATENATED MODULE: ./comments.js
    function render(data, target) {
    console.log('Rendered!');
  }

  // CONCATENATED MODULE: ./index.js
  render();
})

See the difference? In the plain bundle, module 0 was requiring render from module 1. With module concatenation, require is simply replaced with required function, and module 1 is removed. The bundle has fewer modules – and less module overhead!

To turn on this behavior, in webpack 4, enable the optimization.concatenateModules option:

// webpack.config.js (for webpack 4)
module.exports = {
  optimization: {
    concatenateModules: true
  }
};

In webpack 3, use the ModuleConcatenationPlugin:

// webpack.config.js (for webpack 3)
const webpack = require('webpack');

module.exports = {
  plugins: [
    new webpack.optimize.ModuleConcatenationPlugin()
  ]
};

Use `externals` if you have both webpack and non-webpack code #

You might have a large project where some code is compiled with webpack, and some code is not. Like a video hosting site, where the player widget might be built with webpack, and the surrounding page might be not:

(A completely random video hosting site)

If both pieces of code have common dependencies, you can share them to avoid downloading their code multiple times. This is done with the webpack’s externals option – it replaces modules with variables or other external imports.

If dependencies are available in `window` #

If your non-webpack code relies on dependencies that are available as variables in window, alias dependency names to variable names:

// webpack.config.js
module.exports = {
  externals: {
    'react': 'React',
    'react-dom': 'ReactDOM'
  }
};

With this config, webpack won’t bundle react and react-dom packages. Instead, they will be replaced with something like this:

// bundle.js (part of)
(function(module, exports) {
  // A module that exports `window.React`. Without `externals`,
  // this module would include the whole React bundle
  module.exports = React;
}),
(function(module, exports) {
  // A module that exports `window.ReactDOM`. Without `externals`,
  // this module would include the whole ReactDOM bundle
  module.exports = ReactDOM;
})

If dependencies are loaded as AMD packages #

If your non-webpack code doesn’t expose dependencies into window, things are more complicated. However, you can still avoid loading the same code twice if the non-webpack code consumes these dependencies as AMD packages.

To do this, compile the webpack code as an AMD bundle and alias modules to library URLs:

// webpack.config.js
module.exports = {
  output: {
    libraryTarget: 'amd'
  },
  externals: {
    'react': {
      amd: '/libraries/react.min.js'
    },
    'react-dom': {
      amd: '/libraries/react-dom.min.js'
    }
  }
};

Webpack will wrap the bundle into define() and make it depend on these URLs:

// bundle.js (beginning)
define(["/libraries/react.min.js", "/libraries/react-dom.min.js"], function () { … });

If non-webpack code uses the same URLs to load its dependencies, then these files will be loaded only once – additional requests will use the loader cache.

Summing up #

Enable the production mode if you use webpack 4
Minimize your code with the bundle-level minifier and loader options
Remove the development-only code by replacing NODE_ENV with production
Use ES modules to enable tree shaking
Compress images
Apply dependency-specific optimizations
Enable module concatenation
Use externals if this makes sense for you

Monitor and analyze the app

2017-12-18T00:00:00Z

Even when you configure webpack to make the app as small as possible, it’s still important to keep track of it and know what it includes. Otherwise, you can install a dependency that will make the app twice as large – and won’t even notice it!

This section describes tools that help you to understand your bundle.

Keep track of the bundle size #

To monitor your app size, use webpack-dashboard during development and bundlesize on CI.

webpack-dashboard #

webpack-dashboard enhances webpack output with sizes of dependencies, progress and other details. Here’s how it looks:

This dashboard helps to track large dependencies – if you add one, you’ll immediately see it in the Modules section!

To enable it, install the webpack-dashboard package:

npm install webpack-dashboard --save-dev

And add the plugin into the plugins section of the config:

// webpack.config.js
const DashboardPlugin = require('webpack-dashboard/plugin');

module.exports = {
    plugins: [
    new DashboardPlugin(),
    ],
};

or using compiler.apply() if you’re using an Express-based dev server:

compiler.apply(new DashboardPlugin());

Feel free to play with the dashboard to find the probable places for improvement! For example, scroll through the Modules section to find what libraries are too large and could be replaced with smaller alternatives.

bundlesize #

bundlesize verifies that webpack assets don’t exceed the specified sizes. Integrate it with a CI to get notified when the app becomes too large:

To configure it:

Find out the maximum sizes

Optimize the app to make it as small as possible. Run the production build.

Add the bundlesize section into package.json with the following content:

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/*"
    }
  ]
}

Execute bundlesize with npx:

npx bundlesize

This will print the gzipped size of each file:

PASS  ./dist/icon256.6168aaac8461862eab7a.png: 10.89KB
PASS  ./dist/icon512.c3e073a4100bd0c28a86.png: 13.1KB
PASS  ./dist/main.0c8b617dfc40c2827ae3.js: 16.28KB
PASS  ./dist/vendor.ff9f7ea865884e6a84c8.js: 31.49KB

Add 10-20% to each size, and you’ll get the maximum sizes. This 10-20% margin would let you develop the app as usual while warning you when its size grows too much.

Enable bundlesize
Install the bundlesize package as a development dependency:
```
npm install bundlesize --save-dev
```

In the bundlesize section in the package.json, specify the concrete maximum sizes. For some files (e.g., images), you might want to specify the maximum size per file type, not per each file:

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/*.png",
      "maxSize": "16 kB",
    },
    {
      "path": "./dist/main.*.js",
      "maxSize": "20 kB",
    },
    {
      "path": "./dist/vendor.*.js",
      "maxSize": "35 kB",
    }
  ]
}

Add an npm script to run the check:

// package.json
{
  "scripts": {
    "check-size": "bundlesize"
  }
}

Configure the CI to execute npm run check-size on each push. (And integrate bundlesize with GitHub if you’re developing the project on it.)

That’s it! Now, if you run npm run check-size or push the code, you’ll see if the output files are small enough:

Or, in case of failures:

Analyze why the bundle is so large #

You might want to dig deeper into the bundle to see what modules take space in it. Meet webpack-bundle-analyzer:

(Screen recording from github.com/webpack-contrib/webpack-bundle-analyzer)

webpack-bundle-analyzer scans the bundle and builds a visualization of what’s inside it. Use this visualization to find large or unnecessary dependencies.

To use the analyzer, install the webpack-bundle-analyzer package:

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

add a plugin to the webpack config:

// webpack.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin(),
  ],
};

and run the production build. The plugin will open the stats page in a browser.

By default, the stats page shows the size of parsed files (i.e., of files as they appear in the bundle). You’ll likely want to compare gzip sizes since that’s closer to what real users experience; use the sidebar on the left to switch the sizes.

Here’s what to look for in the report:

Large dependencies. Why are they so large? Are there smaller alternatives (e.g., Preact instead of React)? Do you use all the code it includes (e.g., Moment.js includes a lot of locales that are often not used and could be dropped)?
Duplicated dependencies. Do you see the same library repeating in multiple files? (Use, e.g., the optimization.splitChunks.chunks option – in webpack 4 – or the CommonsChunkPlugin – in webpack 3 – to move it into a common file.) Or does the bundle have multiple versions of the same library?
Similar dependencies. Are there similar libraries that do approximately the same job? (E.g. moment and date-fns, or lodash and lodash-es.) Try sticking with a single tool.

Also, check out Sean Larkin’s great analysis of webpack bundles.

Summing up #

Use webpack-dashboard and bundlesize to stay tuned of how large your app is
Dig into what builds up the size with webpack-bundle-analyzer

Ivan Akulov on web.dev

Webpack conclusion

Make use of long-term caching

Use bundle versioning and cache headers #

Further reading #

Extract dependencies and runtime into a separate file #

Dependencies #

Webpack runtime code #

Further reading #

Inline webpack runtime to save an extra HTTP request #

If you generate HTML with the HtmlWebpackPlugin #

If you generate HTML using a custom server logic #

Lazy-load code that you don't need right now #

Further reading #

Split the code into routes and pages #

For single-page apps #

For traditional multi-page apps #

Further reading #

Make module ids more stable #

Further reading #

Summing up #

Decrease front-end size

Use the production mode (webpack 4 only) #

Further reading #

Enable minification #

Bundle-level minification #

Loader-specific options #

Further reading #

Specify NODE_ENV=production #

Further reading #

Use ES modules #

Further reading #

Optimize images #

Further reading #

Optimize dependencies #

Enable module concatenation for ES modules (aka scope hoisting) #

Further reading #

Use externals if you have both webpack and non-webpack code #

If dependencies are available in window #

If dependencies are loaded as AMD packages #

Further reading #

Summing up #

Monitor and analyze the app

Keep track of the bundle size #

webpack-dashboard #

bundlesize #

Further reading #

Analyze why the bundle is so large #

Summing up #

Specify `NODE_ENV=production` #

Use `externals` if you have both webpack and non-webpack code #

If dependencies are available in `window` #