Repository navigation
Server start-up takes too long to boot up. #186
Description
I am facing pretty long build times on development mode, around 50-70 seconds.
I could narrow it down to notice that babel-register and babel-polyfill being required takes way too long to execute even a console statement at the start of server.js file. Any suggestions to speed up this process ? Also, i have replaced cssnext with a less loader along with post-css, but i'm guessing that shouldn't be the cause for the performance hit at server side transpiling since i have fewer .less files.
P.S.
I am running npm@3.9.6,, was thinking may be it was related to this post, but doesn't help.
Reacted by Andi Smith, Jon, Nico Prananta, Guilherme Akio Sakae, Andrew Dassonville, Morgan, Kristijan Franković, Junshan Liu, Hrvoje Hlevnjak, Sergej Jakovljev and 6 more
Activity
zatziky commentedon Jun 29, 2016
I am experiencing the very same problem with fresh installation of mern-starter. The server boots up aroung 1 minute then every change caught by nodemon takes again about 1 min to restart the server.
osenvosem commentedon Jun 30, 2016
Yes, the dev server starts up long time.
froskie commentedon Jul 25, 2016
If you check what
babel-plugin-webpack-loadersdoes, you'll see that yes, it'll take a long time to start the server. It comes with a cost, but it's amazingly helpful. If you're working only with frontend, the refresh will be quite simple, but if you going for server folder, each time it has to restart is a real pain.qlqllu commentedon Oct 15, 2016
From my investigation, the reason is whenever we start or restart the server, the webpack will rebuild all of the related files, this will take a long time
qlqllu commentedon Oct 15, 2016
Here is the related issue: #153
kfrankovic commentedon Oct 24, 2016
I'm experiencing the same issues here. As the project grows (and it is still not very big currently, no more than 10 screens without much functionality), things are getting even worse - we are now on almost 3 minutes for server startup / every change on the server.
Is there any solution for this issue? What especially worries me how long will build times take six months from now once we have much more code.
qlqllu commentedon Oct 25, 2016
+1
kfrankovic commentedon Nov 11, 2016
20 days later, we are at almost 6:30 for server restart. Build speed is deteriorating fast.
amygdaloideum commentedon Nov 20, 2016
@kfrankovic Did you find any solution?
kfrankovic commentedon Nov 20, 2016
@amygdaloideum Actually yes, colleague on the project found a solution this week.
If I'm correct, we now have enabled babel caching (removed BABEL_DISABLE_CACHE flag from startup script) and enabled and configured aggressive caching (unsafe cache) in webpack.config.babel.js for webpack, and server start times are now less than 30 seconds (and most of that is actually webpack, which I wasn't even counting before).
The only new issue we experienced so far is that sometimes it fails to load changes in scss files if you don't make change where scss file is referenced, but this is just a small nuisance compared to 'build' times we had before.
I'll tell colleague to post further instructions tomorrow (I don't know all the details, and don't want to grab his credits for finding the solution).
amygdaloideum commentedon Nov 20, 2016
@kfrankovic Thank you!
hhlevnjak commentedon Nov 21, 2016
@amygdaloideum
As @kfrankovic noted, we managed to improve build times by adding some caching to babel. We added the following loader to webpack.config.babel.js
We also removed the BABEL_DISABLE_CACHE from startup. Even though it's not recommended to do so, there haven't been any side effects that we noted so far. The only one being that sometimes if you edit a css file, the change won't get hot reloaded until you edit the file referencing that css file.
Eligioo commentedon Mar 29, 2018
@hhlevnjak Can you be more specific where you have added the loader into the webpack.config.babal.js?
I managed to remove the BABEL_DISABLE_CACHE from startup tho.
hhlevnjak commentedon Mar 29, 2018
It was just added to the loaders.
Though this was over a year ago, webpack configurations had other problems as well, so we rewrote the whole webpack configuration to match the needs of the project in the meantime.