Server start-up takes too long to boot up.

[raavanan]

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.

[zatziky]

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]

Yes, the dev server starts up long time.

[froskie]

If you check what babel-plugin-webpack-loaders does, 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]

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]

Here is the related issue: #153

[kfrankovic]

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]

+1

[kfrankovic]

20 days later, we are at almost 6:30 for server restart. Build speed is deteriorating fast.

[amygdaloideum]

@kfrankovic Did you find any solution?

[kfrankovic]

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

@kfrankovic Thank you!

[hhlevnjak]

@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

{
    test: /\.js$/,
    exclude: /(node_modules)/,
    loader: 'babel?cacheDirectory',
    query: {
      presets: ['es2015']
    }
  }

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]

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

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.