Create-react-app: Slow production build

Created on 11 Jul 2017  Â·  36Comments  Â·  Source: facebook/create-react-app

Not sure if the project is too large or there is something wrong, but my yarn run build took almost 5 minutes.

image

The project is about 1k5 files:

git ls-files | wc -l
1540

Is it normal? Is there any --debug option to verbosely view the time took to compile the project?

proposal

Most helpful comment

Updated to react-scripts 1.0.11 today (with webpack 3), build time reduced from 280s -> 175s. That's something :)

image

All 36 comments

We'll switch to Webpack 3 soon which will be a tad faster.
Unfortunately there's only so much we can do when underlying tools are slow 😢

I see you're using code splitting—maybe this could help? https://github.com/webpack/webpack/issues/4636#issuecomment-301920118 I'm not sure how exactly you're using it.

Other than that, I don't really have good news for you. You can contribute to webpack to make it faster, or maybe investigate approaches like HappyPack and whether we could switch to them.

I think we can do more to improve build speed. cache-loader improvement can be seen on a large set of files. it cuts about 20-30 seconds on my project. (usually it takes about 90 - 100s) Webpack's UglifyJS plugin can be replaced with https://www.npmjs.com/package/webpack-uglify-parallel and it combined with the cache-loader cuts almost 50% of the build time.

And then there's @asfktz autodll plugin https://github.com/asfktz/autodll-webpack-plugin/. I haven't tested it with a real project, but it's nice to work with him on improving this :)

And at the very least, maybe we can add tests that track how long the build gonna take, with a large number of files.

Switching this internally would, of course, affects stability, maybe we can have a canary channel to test out this? At least, a canary channel of CRA would have more users than an obscurely published fork.

Or have a way to easily install from GitHub branches, without modifying package name etc. In my experience maintaining a fork is hard, especially if I need to modify something that is not in react-scripts. Sometimes when syncing the package name is overwritten, imports are rewritten, etc2

How long does yarn start take for your project?
If it's ~1 minute, I'd love to get my hands on your project if you'd be willing to share it.

@Timer yarn start takes about 2~3 minutes. The project is private so I can't share it 😞

Most client side code isn't very private, 😛.
I could sign an NDA or something similar if needed.

Is this app deployed on the web so I could take a peek?

The app is deployed on the web but can only access via a VPN. It's a huge Admin Panel app for an internal product.

I could talk to the team to see if I can grant you a read permission, would you still willing to take a look if I can get the agreement from the team?

Sure! I would love to have temporary access to the code base to test optimizations against. Build speed is something we're very interested in speeding up.

@viankakrisna uglifyjs plugin now supports parallel out-of-the-box.

https://github.com/webpack-contrib/uglifyjs-webpack-plugin/#parallel

@trungdq88 any word on that repo? 😄

@Timer sorry for being inactive. It is under consideration and we need sometime to prepare something like NDA (we have never done this before). Hopefully I can have the answer for you in the next 2 days.

I'm going to be out of town until next week, just a heads up! So no rush.

@miraage can we enable it with our current webpack version?

@viankakrisna it works for me like a charm in my pet project (webpack 3.4). The problem is that plugin currently in beta status.

We'll hold off on enabling it until it's considered stable. :)

I wish CRA has an experimental version, just to test cutting edge feature with lots of user and case 😄

@viankakrisna yeah I also wouldn't mind having some fork with latest features :D

It should be promoted "officially" by CRA so more people can test drive it :)

Updated to react-scripts 1.0.11 today (with webpack 3), build time reduced from 280s -> 175s. That's something :)

image

Nice, thanks for checking! You can also add GENERATE_SOURCEMAP=false to .env file if you're okay with missing sourcemaps. This should make it faster yet. (But I don't recommend skipping sourcemaps because then you can't debug production errors.)

I wish CRA has an experimental version

File an issue for this? I'm not opposed to having an opt in way to beta test features before they're enabled for everybody.

Setting GENERATE_SOURCEMAP=false cut down our build time by about a third.

Disabling eslint preloader also decreases build time.

How do you guys disable eslint?

^ ejecting?

found an interesting issue about eslint-loader / eslint perf https://github.com/MoOx/eslint-loader/issues/206

@viankakrisna Good find

Is there no way to disable eslint via an environment variable when building without ejecting?

Any movement on this? I've got a project where the CRA Build is the overwhelming majority of the time. It's a Maven project - the CRA app is the frontend for a Java webapp. The entire Maven build for my frontend takes 40s, including:

  • yarn install - 0.78s
  • yarn build - 31s
  • yarn flow - 0.23s
  • yarn test - 5s

So just building the production frontend files is over 3/4 of the build time.

This is using CRA as it comes, with no ejecting or anything like that, and only has 26 source files.

Installed new CRA@next (npx create-react-app@next --scripts-version=2.0.0-next.9754a231) - npm run build time decrease:

Old setup:
npm run build 75.44s user 2.76s system 123% cpu 1:03.35 total

New setup:
npm run build 170.59s user 9.72s system 238% cpu 1:15.61 total

Environment:

  • project is ejected;
  • Node: v9.8.0
  • NPM: v5.6.0
  • machine: MacBook Pro 15 (2013), Intel Core i7 2.3 GHz (4 cores), RAM: 16 GB, SSD

I can provide full config difference from default 2.0.0-next.9754a231 setup on request.

The bulk of all optimizations have made it into the 2.0 beta, barring webpack 4.

@sidoruk-sv if you're reporting a build time regression, please open a new issue.

@Timer one more thing)

That was my misunderstanding of time output (looked at user time, but should on total)

So tried latest: npx create-react-app@next --scripts-version=2.0.0-next.b2fd8db8

and re-check build time for old and new configs:

Old:
time npm run build:


  • npm run build 72.09s user 2.52s system 122% cpu 1:00.88 total
  • npm run build 70.55s user 2.51s system 125% cpu 58.098 total

gtime npm run build:


  • 69.45user 2.50system 0:56.86elapsed 126%CPU

*New:
*
time npm run build:

  • npm run build 98.71s user 5.29s system 266% cpu 39.096 total
  • npm run build 102.98s user 5.95s system 283% cpu 38.404 total

gtime npm run build:

  • 105.72user 5.40system 0:42.46elapsed 261%CPU
  • 100.73user 6.09system 0:37.64elapsed 283%CPU


So build time (total/elapsed) decrease by ~10-20s

(for my config)

You guys are cool!
You make continuous improvements that enhance the quality of developer's life, thanks for your work.

Neat. The next 2.0 release will be even quicker, stay tuned!

I was playing with webpackChunkName and my build time was decreased from ~3 mins to 34 sec. 🚀

I'm using react-loadable for all dynamic imports, but somehow build time was weird (because of many components). So, I have replaced this:

loader: () => import(`components/${component}`)

to:

loader: () => import(/* webpackChunkName: "components/[request]" */ `components/${component}`)

and as result: almost in 6x times build time is faster now. Hope it will help somebody.

p.s. more info about import here: https://webpack.js.org/api/module-methods/#import-

interesting, can that comment be inserted automatically with a babel plugin / other wizardry?

I can se react-script is using webpack 3 right now, but I feel that it is still slow, do you think we should have automatically build to ignore the waiting time?

@Timer one more thing)

That was my misunderstanding of time output (looked at user time, but should on total)

So tried latest: npx create-react-app@next --scripts-version=2.0.0-next.b2fd8db8

and re-check build time for old and new configs:

Old:
time npm run build:


  • npm run build 72.09s user 2.52s system 122% cpu 1:00.88 total
  • npm run build 70.55s user 2.51s system 125% cpu 58.098 total

gtime npm run build:


  • 69.45user 2.50system 0:56.86elapsed 126%CPU

*New:
*
time npm run build:

  • npm run build 98.71s user 5.29s system 266% cpu 39.096 total
  • npm run build 102.98s user 5.95s system 283% cpu 38.404 total

gtime npm run build:

  • 105.72user 5.40system 0:42.46elapsed 261%CPU
  • 100.73user 6.09system 0:37.64elapsed 283%CPU


So build time (total/elapsed) decrease by ~10-20s

(for my config)

You guys are cool!
You make continuous improvements that enhance the quality of developer's life, thanks for your work.

do you solve the build slowly?Thank you!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jnachtigall picture jnachtigall  Â·  3Comments

ap13p picture ap13p  Â·  3Comments

adrice727 picture adrice727  Â·  3Comments

AlexeyRyashencev picture AlexeyRyashencev  Â·  3Comments

oltsa picture oltsa  Â·  3Comments