create-react-app: Slow production build

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?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 3
  • Comments: 36 (25 by maintainers)

Most upvoted comments

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

image

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.

@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.

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.

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

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.

^ ejecting?

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

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.)

@viankakrisna yeah I also wouldn’t mind having some fork with latest features 😄

We’ll hold off on enabling it until it’s considered stable. 😃

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

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

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

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