Decrease Front-end Size

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.

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:

Note: In webpack 3, the UglifyJS plugin can’t compile the ES2015+ (ES6+) code. This means
that if your code uses classes, arrow functions or other new language features,
and you don’t compile them into ES5, the plugin will throw an error.

If you need to compile the new syntax, use the
uglifyjs-webpack-plugin package. This
is the same plugin that’s bundled with webpack, but newer, and it’s able to compile the ES2015+
code.

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:

Specify NODE_ENV=production

Another way to decrease the front-end size is to set the NODE_ENVenvironmental 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:

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:

Further reading

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:

Note: In webpack, tree-shaking doesn’t work without a minifier. Webpack just removes export
statements for exports that aren’t used; it’s the minifier that removes unused code.
Therefore, if you compile the bundle without the minifier, it won’t get smaller.

If you use Babel with babel-preset-env or babel-preset-es2015, check the settings of these
presets. By default, they transpile ES’ import and export to CommonJS’ require and
module.exports. Pass the { modules: false }
option to disable this.

The same with TypeScript: remember to set { "compilerOptions": { "module": "es2015" } }
in your tsconfig.json.

Further reading

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:

// 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`

Note: Inlined images reduce the number of separate requests, which is good (even with
HTTP/2), but increase the
download/parse time of your bundle and memory consumption. Make sure to not embed large images or a
lot of them – or increased bundle time would outweigh the benefit of inlining.

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:

Note: svg-url-loader has options that improve Internet Explorer support, but worsen inlining for
other browsers. If you need to support this browser, apply the iesafe: true
option.

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':

Further reading

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!

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:

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:

Further reading

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:

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:

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.

Note: Webpack replaces only those imports that exactly match keys of the externals object. This
means that if you write import React from 'react/umd/react.production.min.js', this library won’t
be excluded from the bundle. This is reasonable – webpack doesn’t know if import 'react' and
import 'react/umd/react.production.min.js' are the same things – so stay careful.