Christian Nwamba JS preacher. Developer 🥑. Building the web with the community @concatenateConf @forLoopAfrica. JS and Senior Advocacy for the Next Billion Users through Microsoft.

Quick guide to webpack bundle and code splitting with React

2 min read 590


You’re probably here because your app has grown to the point where forcing the user to download the entire thing as a single file seems cruel and unusual. Fact is, tons of features and a complex UX are bound to affect the amount of code you’re working with. What to do?

Easy. Make a “vendor bundle.” A vendor bundle contains all the frameworks and libraries each application feature depends on. By building all this code into a single bundle, the client can effectively cache the bundle, and you only need to rebuild the bundle when a framework or library updates.

It’s also worth considering that every time your application is updated or changed, the client must download new vendor dependencies. What to do?

You guessed it. Bundle ’em up. Put the parts that changed in one bundle and the dependencies in another. That way, the client only downloads what it needs.

In this post, I’ll walk you through the basics of bundle splitting in Webpack. As you might expect, I’ll also touch on code splitting.

How to create a vendor bundle

Assuming you have a basic React application, execute npm run build in CLI to get a baseline build:

Hash: 9db5a05e09ad73897fd4
  Version: webpack 2.2.1
  Time: 2114ms
          Asset       Size  Chunks                    Chunk Names
    ...font.eot     166 kB          [emitted]
  ...font.woff2    77.2 kB          [emitted]
   ...font.woff      98 kB          [emitted]
    ...font.svg     444 kB          [emitted]  [big]
       logo.png      77 kB          [emitted]
    ...font.ttf     166 kB          [emitted]
         app.js     170 kB       0  [emitted]         app
        app.css    3.11 kB       0  [emitted]         app     193 kB       0  [emitted]         app   89 bytes       0  [emitted]         app
     index.html  248 bytes          [emitted]
     [0] ./~/process/browser.js 7.3 kB {0} [built]
     [3] ./~/react/lib/ReactElement.js 13.2 kB {0} [built]
    [18] ./app/component.js 292 bytes {0} [built]

As you can see, theapp is quite large — about 170kb. That’s something you’ll fix in our upcoming example.

Code splitting

Code Splitting is an awesome feature that splits your codebase into various, smaller bundles which can be loaded whenever they are needed.

What this means is that your application is composed of lots of small code files (as modules) which are called “chunks”. If used properly, code splitting will lower loading time. Webpack allows you to define split points in your code base and then takes care of the dependencies, output files and runtime stuff.

Let’s proceed to walk through the most common approaches to code splitting when using Webpack.

Asynchronous Loading

This is just basically splitting code by loading the modules asynchronously. Say you have this directory with Lodash in the node_modules:

|- package.json 
|- webpack.config.js 
|- /dist 
|- /src 
  |- index.js
|- /node_modules

In the index.js file, import lodash using Common JS require.ensure. As the method name goes, it ensures that the module is only loaded when the code is required and it does this asynchronously:

require.ensure(['lodash'],  function() {
  var lodash = require('lodash');

You don’t need to change anything in the Webpack configuration:

const path = require('path');
const HTMLWebpackPlugin = require('html-webpack-plugin');
module.exports = {
  entry: {
    index: './src/index.js'
  plugins: [
    // ...
  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'dist')

Running npm run build in our CLI will yield the following build result:

Hash: a27e5bf1dd73c675d5c9
Version: webpack 2.6.1
Time: 544ms
           Asset     Size  Chunks                    Chunk Names
lodash.bundle.js   541 kB       0  [emitted]  [big]  lodash
 index.bundle.js  6.35 kB       1  [emitted]         index
   [0] ./~/lodash/lodash.js 540 kB {0} [built]
   [1] ./src/index.js 377 bytes {1} [built]
   [2] (webpack)/buildin/global.js 509 bytes {0} [built]
   [3] (webpack)/buildin/module.js 517 bytes {0} [built]


LogRocket: Full visibility into your production React apps

Debugging React applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.

LogRocket combines session replay, product analytics, and error tracking – empowering software teams to create the ideal web and mobile product experience. What does that mean for you?

Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay problems as if they happened in your own browser to quickly understand what went wrong.

No more noisy alerting. Smart error tracking lets you triage and categorize issues, then learns from this. Get notified of impactful user issues, not false positives. Less alerts, way more useful signal.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your React apps — .

Christian Nwamba JS preacher. Developer 🥑. Building the web with the community @concatenateConf @forLoopAfrica. JS and Senior Advocacy for the Next Billion Users through Microsoft.

Leave a Reply