Webpack 2 Dynamic Import degrades build performance (slow) compared to static imports. #4636

AustinHunt · 2017-04-04T18:18:40Z

Do you want to request a feature or report a bug?
I would like to report a bug.

What is the current behavior?
When converting my project's components to dynamically import components instead of using static import statements, the build time increases by 10x and incremental builds by about the same.

The dynamic import functionality has reduced my bundle size astronomically by breaking all of my react components into separate chunks that get loaded into the app on-demand. I used a react-loader setup to replace most of my component static imports with dynamic imports.

If the current behavior is a bug, please provide the steps to reproduce.

Create a large number static imports in your project.
Convert those imports into dynamic imports.
Run webpack-dev-server with hot-reloading for both and compare the build time.

//Static Example: index.js
import ComponentA from './component-a';
import ComponentB from './component-b';

export { ComponentA, ComponentB }

//Dynamic Example: index.js
import Loadable from 'react-loadable';

const LoadingComponent = f => {
  return (
    <div style={{textAlign:'center'}}><i className="fa fa-spinner fa-spin fa-2x"></i></div>
  )
}

const LoadableComponent = opts => {
  return Loadable({
    delay: 300,
    LoadingComponent,
    ...opts,
  })
}

const ImportLoadable = (loader) => {
  const Component = LoadableComponent({
    loader
  });

  return Component;
}

const ComponentA = ImportLoadable(f => import('./component-a'));
const ComponentB = ImportLoadable(f => import('./component-b'));

export { ComponentA, ComponentB }

What is the expected behavior?
I expect the dynamic import build time to be the same as a static import build time.

If this is a feature request, what is motivation or use case for changing the behavior?
It seems that even though the dynamic import automatically chunks your bundle into multiple files, that when changing the underlying code for one of those chunks, webpack should be able to detect which file that was and only rebuild that file and hot-reload it.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Webpack 2.3.2
Webpack-Dev-Server 2.4.2

AustinHunt · 2017-04-04T18:24:16Z

As a side note, I couldn't find an exact replica issue for this bug. #4582 seems to be a similar problem?

AustinHunt · 2017-04-04T19:23:25Z

Temporary workaround we found:

import { ImportLoadable } from '../';
let Account;
let AccountContainer;
let AddCard;
let EditCard;
let DeleteCard;
let CardForm;
let Cards;
let Card;
let Charges;
let Charge;
let Invoices;
let Invoice;
let PurchaseMap;
let PurchasePlan;

if(process.env.NODE_ENV == 'production') {
	Account = ImportLoadable(f => import('./account'));
	AccountContainer = ImportLoadable(f => import('./accountContainer'));
	AddCard = ImportLoadable(f => import('./addCard'));
	EditCard = ImportLoadable(f => import('./editCard'));
	DeleteCard = ImportLoadable(f => import('./deleteCard'));
	CardForm = ImportLoadable(f => import('./cardForm'));
	Cards = ImportLoadable(f => import('./cards'));
	Card = ImportLoadable(f => import('./card'));
	Charges = ImportLoadable(f => import('./charges'));
	Charge = ImportLoadable(f => import('./charge'));
	Invoices = ImportLoadable(f => import('./invoices'));
	Invoice = ImportLoadable(f => import('./invoice'));
	PurchaseMap = ImportLoadable(f => import('./purchaseMap'));
	PurchasePlan = ImportLoadable(f => import('./purchasePlan'));
}
else {
	Account = require('./account');
	AccountContainer = require('./accountContainer');
	AddCard = require('./addCard');
	EditCard = require('./editCard');
	DeleteCard = require('./deleteCard');
	CardForm = require('./cardForm');
	Cards = require('./cards');
	Card = require('./card');
	Charges = require('./charges');
	Charge = require('./charge');
	Invoices = require('./invoices');
	Invoice = require('./invoice');
	PurchaseMap = require('./purchaseMap');
	PurchasePlan = require('./purchasePlan');
}

export {
	Account,
	AccountContainer,
	AddCard,
	EditCard,
	DeleteCard,
	CardForm,
	Cards,
	Card,
	Charges,
	Charge,
	Invoices,
	Invoice,
	PurchaseMap,
	PurchasePlan
}

UDPATE: ^^^This actually did not work.

sokra · 2017-04-04T19:32:43Z

do you have a repo for profiling?

Vanuan · 2017-04-08T21:41:39Z

I have this too. ~50 chunks with require.ensure results in increase of build time from 120 seconds to 500 seconds which is almost 10 minutes!

Does it mean that each entrypoint results in a fresh evaluation of its dependency tree?

AustinHunt · 2017-04-10T14:08:07Z

I have a shallow understanding of webpack, so I'm unsure. I would make a pull request with the change if I can be pointed in the right direction to fix the issue.

Vanuan · 2017-04-10T14:30:35Z

I've tried this syntax and it's much better:

               require.ensure(['./container'], require => {
                       cb(null, require('./container').default);
               })

sokra · 2017-04-11T06:54:29Z

do you have a repo for profiling?

niieani · 2017-04-16T08:37:17Z

Related to #4716

peterdotjs · 2017-04-21T05:08:40Z

@Vanuan a temporary workaround I've used is to strip out require.ensure during development. using https://github.com/knpwrs/babel-plugin-remove-webpack as noted in #4716. One caveat is that this stripping out needs to be done outside of Webpack through babel command line.

AustinHunt · 2017-04-21T09:35:01Z

@peterdotjs looks like babel-plugin-remove-webpack does not in-fact remove webpack 2 dynamic import syntax. See docs

peterdotjs · 2017-04-21T14:19:36Z

@NomadGraphix I was referring specifically to require.ensure but the same general technique (with a different plugin) could be used for the dynamic import syntax that you specified.

ingro · 2017-05-16T13:14:38Z

I'm facing this issue too, converting a lot of require.ensure calls to use the new dynamic import crippled down massively the building time.

ingro · 2017-05-16T16:04:37Z

I've created a small repo to help reproduce the problem here.

Just clone and npm install, then you can run two commands:

npm run import: run the web server using dynamic imports;
npm run require: run the web server using require.ensure syntax

The repo and the files included are very small so the difference is not that big but if you modify a random file it's usually taking ~300/400ms to rebuild with require.ensure versus ~700/800ms with import (the problem is way more evident in real apps).

Also if you edit a file with require.ensure here's the output:

webpack: Compiling...
Hash: 01801f65cbafafb802d7
Version: webpack 2.5.1
Time: 442ms
                                   Asset       Size  Chunks                    Chunk Names
                           0.requires.js    2.92 MB       0  [emitted]  [big]
                             requires.js     346 kB       1  [emitted]  [big]  main
    0.3e7d4048a4682840be2d.hot-update.js  844 bytes       0  [emitted]
    3e7d4048a4682840be2d.hot-update.json   43 bytes          [emitted]
                       0.requires.js.map    3.08 MB       0  [emitted]
0.3e7d4048a4682840be2d.hot-update.js.map  478 bytes       0  [emitted]
                         requires.js.map     408 kB       1  [emitted]         main
webpack: Compiled successfully.

versus this using import:

webpack: Compiling...
Hash: 8bbc15d48815f50afd15
Version: webpack 2.5.1
Time: 747ms
                                    Asset       Size  Chunks                    Chunk Names
     d71b0f87e6ade357067e.hot-update.json   44 bytes          [emitted]
                             0.imports.js    1.96 MB       0             [big]
                             2.imports.js    1.49 MB       2             [big]
                             3.imports.js    1.49 MB       3             [big]
                             4.imports.js    1.49 MB       4             [big]
                             5.imports.js    1.49 MB       5             [big]
                             6.imports.js    1.49 MB       6             [big]
                             7.imports.js    1.49 MB       7             [big]
                             8.imports.js    1.49 MB       8             [big]
                             9.imports.js    1.49 MB       9             [big]
                            10.imports.js    1.49 MB      10             [big]
                            11.imports.js    1.49 MB      11             [big]
                            12.imports.js    1.49 MB      12             [big]
                            13.imports.js    1.49 MB      13             [big]
                            14.imports.js    1.49 MB      14             [big]
                            15.imports.js    1.49 MB      15             [big]
                            16.imports.js    1.13 MB      16             [big]
                            17.imports.js     681 kB      17             [big]
                            18.imports.js     141 kB      18
                            19.imports.js     141 kB      19
                            20.imports.js     141 kB      20
                            21.imports.js     141 kB      21
                            22.imports.js     141 kB      22
                            23.imports.js     141 kB      23  [emitted]
                            24.imports.js     141 kB      24
                               imports.js     421 kB      25  [emitted]  [big]  main
    23.d71b0f87e6ade357067e.hot-update.js  850 bytes      23  [emitted]
                             1.imports.js    1.49 MB       1             [big]
                         0.imports.js.map    2.05 MB       0
                         1.imports.js.map    1.47 MB       1
                         2.imports.js.map    1.47 MB       2
                         3.imports.js.map    1.47 MB       3
                         4.imports.js.map    1.47 MB       4
                         5.imports.js.map    1.47 MB       5
                         6.imports.js.map    1.47 MB       6
                         7.imports.js.map    1.47 MB       7
                         8.imports.js.map    1.46 MB       8
                         9.imports.js.map    1.47 MB       9
                        10.imports.js.map    1.47 MB      10
                        11.imports.js.map    1.47 MB      11
                        12.imports.js.map    1.47 MB      12
                        13.imports.js.map    1.47 MB      13
                        14.imports.js.map    1.47 MB      14
                        15.imports.js.map    1.47 MB      15
                        16.imports.js.map    1.28 MB      16
                        17.imports.js.map     812 kB      17
                        18.imports.js.map     169 kB      18
                        19.imports.js.map     169 kB      19
                        20.imports.js.map     169 kB      20
                        21.imports.js.map     169 kB      21
                        22.imports.js.map     169 kB      22
                        24.imports.js.map     169 kB      24
                        23.imports.js.map     168 kB      23  [emitted]
23.d71b0f87e6ade357067e.hot-update.js.map  481 bytes      23  [emitted]
                           imports.js.map     502 kB      25  [emitted]         main
webpack: Compiled successfully.

gaearon · 2017-05-16T21:24:12Z

From a brief chat with @sokra, my impression that #4636 (comment) does not actually demonstrate a perf regression, but rather the difference in how require.ensure() and import() work. (Correct me if I’m wrong.)

With require.ensure(), anything you require() in the block becomes a part of one chunk. So this example puts all the “dynamic” modules (which we have a lot if we use dynamic expressions) in one JS chunk. This seems worse for the app performance, as, for example, if you load locale files based on current language with a statement like this, you’re going to load all of them in one file. But it’s faster to process at build time. This behavior seems optimal if bundles contain a lot of common code, and so it's not a big deal to combine them together.

With import(), however, every single possible match gets its own chunk. This seems better for the app performance, and it maps more intuitively to how you’d expect it to work, but is worse for the build performance because of all those chunks. This behavior seems optimal if bundles are different enough and contain little common code (of if you rarely need to switch them).

So require.ensure() default behavior seems to work better for things like component trees, but import() default behavior seems to work better for things like locales.

~~Frankly, I don’t know what the intended solution is here, but I’d love to hear more from Webpack folks on how this feature should be used, and what the intended performance is.~~

Apparently the import() default behavior is different from require.ensure() default behavior, but you will be able to customize it with hints to the import() call: #4807 (comment).

ingro · 2017-05-17T08:21:17Z

Thanks for the insight @gaearon , I thought that using import or require.ensure was just a matter of syntax, while it's clear now that they behave very differently. I'll wait for the hints to be implemented for the import syntax, untile then I need to stick to the old require.ensure.

AustinHunt · 2017-05-17T19:10:04Z

@gaearon, this makes quite a bit of sense. My though for a solution is to have an option that allows us to disable dynamic import and require.ensure in development. The main reason I use import and require.ensure are to chunk in production.

We are willing to have a longer build time for pushing to production, but it is debilitating for development.

webpack-bot · 2018-05-23T23:31:57Z

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

webpack-bot · 2018-06-08T02:01:57Z

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

pratikt-cuelogic · 2018-07-18T14:51:57Z

is this applicable for latest versions as well ?
I am using webpack 3.5.x and recently modified implementation for Dynamic Import using react-loadable and feel that build time has been increased.

Please suggest better solution to do so

sokra added the performance label Apr 4, 2017

gaearon mentioned this issue May 16, 2017

Webpack 2 Dynamic Imports are Very Slow facebook/create-react-app#2176

Closed

dvdzkwsk mentioned this issue May 29, 2017

Use import() instead of require.ensure for async split dvdzkwsk/react-redux-starter-kit#1258

Closed

gaearon mentioned this issue Jul 11, 2017

Slow production build facebook/create-react-app#2763

Closed

PanJiaChen mentioned this issue Nov 22, 2017

only want dynamic Imports in production environment #5996

Closed

webpack-bot added the inactive label May 23, 2018

webpack-bot closed this as completed Jun 8, 2018

PanJiaChen mentioned this issue Nov 29, 2018

请问为什么动态路由会影响热更新速度呢，文章写的是说'可能导致了缓存失效'，我想得到一个让人信服的答案。或者切实的证据。 PanJiaChen/vue-element-admin#1376

Closed

chenyiqiao mentioned this issue Jan 8, 2019

[Build Performance] chunk graph very much slow #8557

Closed

edmorley mentioned this issue Jan 24, 2019

[webpack-5] Default webpackMode to "eager" in mode: "development" #8644

Open

yuxino mentioned this issue Jun 3, 2019

我是如何去提升我项目构建的速度的 yuxino/blog#87

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Webpack 2 Dynamic Import degrades build performance (slow) compared to static imports. #4636

Webpack 2 Dynamic Import degrades build performance (slow) compared to static imports. #4636

AustinHunt commented Apr 4, 2017 •

edited

AustinHunt commented Apr 4, 2017 •

edited

AustinHunt commented Apr 4, 2017 •

edited

sokra commented Apr 4, 2017

Vanuan commented Apr 8, 2017 •

edited

AustinHunt commented Apr 10, 2017

Vanuan commented Apr 10, 2017

sokra commented Apr 11, 2017

niieani commented Apr 16, 2017

peterdotjs commented Apr 21, 2017

AustinHunt commented Apr 21, 2017

peterdotjs commented Apr 21, 2017

ingro commented May 16, 2017

ingro commented May 16, 2017

gaearon commented May 16, 2017 •

edited

ingro commented May 17, 2017

AustinHunt commented May 17, 2017 •

edited

webpack-bot commented May 23, 2018

webpack-bot commented Jun 8, 2018

pratikt-cuelogic commented Jul 18, 2018

Webpack 2 Dynamic Import degrades build performance (slow) compared to static imports. #4636

Webpack 2 Dynamic Import degrades build performance (slow) compared to static imports. #4636

Comments

AustinHunt commented Apr 4, 2017 • edited

AustinHunt commented Apr 4, 2017 • edited

AustinHunt commented Apr 4, 2017 • edited

sokra commented Apr 4, 2017

Vanuan commented Apr 8, 2017 • edited

AustinHunt commented Apr 10, 2017

Vanuan commented Apr 10, 2017

sokra commented Apr 11, 2017

niieani commented Apr 16, 2017

peterdotjs commented Apr 21, 2017

AustinHunt commented Apr 21, 2017

peterdotjs commented Apr 21, 2017

ingro commented May 16, 2017

ingro commented May 16, 2017

gaearon commented May 16, 2017 • edited

ingro commented May 17, 2017

AustinHunt commented May 17, 2017 • edited

webpack-bot commented May 23, 2018

webpack-bot commented Jun 8, 2018

pratikt-cuelogic commented Jul 18, 2018

AustinHunt commented Apr 4, 2017 •

edited

AustinHunt commented Apr 4, 2017 •

edited

AustinHunt commented Apr 4, 2017 •

edited

Vanuan commented Apr 8, 2017 •

edited

gaearon commented May 16, 2017 •

edited

AustinHunt commented May 17, 2017 •

edited