Next.js: Slow page build time in development with Next.js 5.0 (compared to Next.js 4.2.3)

[iaincollins]

• [X] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Using previous releases of Next.js build time for pages in development mode as been more or less instant (taking at most a second or two to build a page for the first time, with changes being hot reloaded instantly).

Current Behavior

When using Next.js 5.0 build times for pages in development mode are much slower, often taking several (e.g. 5-10) seconds both for initial page build and for a change to be hot reloaded.

I am seeing this same issue across multiple codebases, and someone has raised it as a performance issue against nextjs-starter project, which recently upgraded to 5.0: https://github.com/iaincollins/nextjs-starter/issues/67

Steps to Reproduce

1. Clone example project 'https://github.com/iaincollins/nextjs-starter' and start with npm run dev.
2. Observe performance building pages with Next.js 5.
3. Stop it and run npm i [email protected] --save and start again with npm run dev.
4. Observe much better performance building pages.

Context

I don't see this issue on very small sites (4-5 pages, no components) but I see it across all production Next.js sites I run, so it's not just project specific for me.

I appreciate it might still be something specific I am doing in those projects, or perhaps just because they all have more components involved.

I'm not sure how best to investigate what's causing this (and was a bit uncomfortable raising an issue without a better understanding of how to diagnose it) but as the performance is fine with Next.js 4, it seemed worth raising as an issue as I assume I'm not the only one impacted and if there are things I'm doing that can be avoided to improve performance then it's good to know what they are for others too.

Your Environment

| Tech | Version |
|---------|---------|
| next | 5.0 |
| node | 7.10.1 |
| OS | macOS 10.13.2 |
| browser | Chrome, Safari |

[jimmylee]

I am also running into this issue on a site with a custom server, 20+ pages, in local development. Some of my build times have taken over 8000ms, and sometimes they hang and nothing happens at all.

Switching back to NextJS 4.2.3 resolved the issue for me, thanks for posting this @iaincollins.

[timneutkens]

@iaincollins https://github.com/iaincollins/nextjs-starter/blob/master/next.config.js#L4-L19
Note that webpack is ran twice, once for the server, and once for the client. You can distinguish them using isServer. This means that all styles are compiled twice in this case.
Also, you're importing things like bootstrap into the sass entrypoint, sass-loader/webpack doesn't cache @imports in sass files, causing every change you make to compile bootstrap twice.
I'd like to further investigate this, but this is a starting point 🙏

[iaincollins]

Thanks Tim, that's super helpful as ever! :)

I'll start with that and follow up with what @jimmmylee was saying by comparing performance with a non-custom server to see if that makes a difference too.

I'd tried using the new approach for sass but didn't like the flash on initial load, but I see from another issue there is a fix for that in a call release already.

I'm sure you are busy and I don't want to make an issue about any specific project of mine, but rather just try and figure out general things that might be better handled differently now, so I will do some digging with the info I have and update with what I find.

[timneutkens]

Happy to help! Maybe we can make an upgrade guide from next 4 to next 5. There's probably more people running into this.

One idea I had is to move bootstrap into a different entrypoint, and importing it in _document.js using my SSR css imports work (in an open PR on next-plugins). Not sure if it'll work, but it'd solve the issue where bootstrap is compiled every single time.

[khuezy]

I don't think the sass imports are root issue. I'm still getting long compile times after removing them :(

[albinekb]

I'm seeing super slow build times in dev mode, it there a way we could cache stuff like styles and components (like my layout that doesn't change much)? That would help a lot.

[develomark]

I'm also running into this issue. It's become really slow with each hot reload. I have sass being imported into styled jsx. Is that the root cause?

[plag]

@develomark same issue, but have sass imported as module into style-loader.
Can not rollback to branch 4, because separate server and client config makes possible import sass files as modules without styled components. Like it.
Tried enable ignore-loader on sass files instead another loaders (it does on server-side config, but i manually try enable it in front config), hot reloading time still bigger than 4.2.3 and same than before.
Wait for main contributors ideas.

[khuezy]

try out the latest next release: canary 6

canary < 6: hot reload build time was between 4-12 seconds
canary 6: hot reload build time: 2-3 seconds.

edit: nvm, it's still slow

[plag]

@khuezy hot reload simply broken and not working in canary6 :)

[khuezy]

@plag hmm, hot reload is working for me in 6.

Try canary.7, dev compile times are more reasonable. ~2-4 seconds on complete build and < 2 seconds on file change.

[bryan]

Still taking me 15+ seconds to compile on my project on canary.7. Not even close to 4.2.3 yet.

[timneutkens]

@plag @bryan it's impossible to debug it's slow or it's broken. Note that it can be numerous factors. So please provide a minimal reproduction, besides the one @iaincollins already provided 😄 Then I can have a look into it 👍 Thanks 🙏

[bryan]

@timneutkens It was more for khuezy's response, in case people start reading the end thinking it's fixed on the canary builds. But I'll keep my pains to a minimum.

[khuezy]

@bryan
I'm not sure why we're seeing different dev build times.

Did you try to remove the node_modules and re installing?

[plag]

@timneutkens prepared simple projects for test
https://github.com/plag/nextjs-slowtest4
https://github.com/plag/nextjs-slowtest5

In readme you can watch live examples and results. Here is average diff is 2x slower on v5.
In my real project (with same structure as demo apps but much more components) on v5 hot reload takes 1.7s vs ~500ms on v4.2.3.

upd: canary8 - hot reload is back but still slow :)

[sheerun]

Since next.js 5 I also started getting mobx issues like:

[mobx] Warning: there are multiple mobx instances active. This might lead to unexpected results. See https://github.com/mobxjs/mobx/issues/1082 for details.

I think I'll rollback for now..

[krokhale]

Yeah rolling back, it's literally getting my Macbook pro to a standstill after a few hours of dev.

[mtford90]

This is a huge problem for me - with next 5 my builds can take upwards of 15s and my laptop grinds to a halt. On next 4 it's more like a few hundred milliseconds.

[timneutkens]

I don't want to repeat myself. But:

it's impossible to debug it's slow or it's broken. Note that it can be numerous factors. So please provide a minimal reproduction, besides the one @iaincollins already provided 😄 Then I can have a look into it 👍 Thanks 🙏

[AaronDDM]

I'll try and investigate this further - however: I have noticed my development environment is using a production React build. This doesn't occur with a fresh build of next.js (no custom Express server setup).

I'm wondering if anyone with this issue is noticing the same thing?

EDIT: Seems only to occur for some components (probably a React chrome extension bug).

[gabrielmancini]

anyone here are using on next.config.js

const withSass = require('@zeit/next-sass');
module.exports = withSass({})

maybe can be this

[timneutkens]

Starting to feel like a robot 😅

I don't want to repeat myself. But:

it's impossible to debug it's slow or it's broken. Note that it can be numerous factors. So please provide a minimal reproduction, besides the one @iaincollins already provided 😄 Then I can have a look into it 👍 Thanks 🙏

[iaincollins]

Sorry I haven't had time to provide more info on this yet BTW, I will try and do more digging soon.

[timneutkens]

@iaincollins you and @plag actually are the only ones that did provide an example 😄

[Attidd]

Edit: Ok, I was wrong. Compile time dropped by 90% by removing the component imports.
This line single-handedly, makes compile time go up from 730 MS to 8000-16474
import { Button, Icon } from "semantic-ui-react";

---

Ignore everything below this, I don't think my issue is related to anyone else after all. I am not sure how a component import could do this much.

---

@gabrielmancini This seems to be the problem on my end. I went from 730 MS to 8000-16474ms.

The only changes I made were setting up Semantic UI theme and importing external CSS to change the design of a simple login page.
There's nothing else beyond that, I have 2 separate branches to confirm this is the issue. I'm going to go down the list to try to replicate exactly at what point this issue came up, and come back here to post an update.

It's a consistent 10-20X increase in compile time even when only changing a single letter.

Here's my next.config.js file.

const withCss = require('@zeit/next-css')

module.exports = withCss({
  webpack (config) {
    config.module.rules.push({
      test: /\.(png|svg|eot|otf|ttf|woff|woff2)$/,
      use: {
        loader: 'url-loader',
        options: {
          limit: 100000,
          publicPath: './',
          outputPath: 'static/',
          name: '[name].[ext]'
        }
      }
    })

    return config
  }
})

Here's the branch in case anyone wanted 2 different branches to compare compile time with.
https://github.com/Attidd/ehex391/pull/1

[JonAbrams]

Has anyone been able to replicate what @Attidd found? My project has hundreds of files that use component imports, and don't think I want to (or should) convert them all, especially if it's not confirmed to help.

Could this be a problem with tree shaking?

[JonAbrams]

Out of desperation I tried @hipabloangel's solution from a different issue.

I was able to fix my slowdown issues in 5.1 by adding this to next.config.js:

module.exports = withSass({
  webpack(config, { dev }) {
    if (dev) {
      config.devtool = 'cheap-module-source-map';
    }
    return config;
  }
});

I have no idea why this works, but I guess for some reason it's expensive to generate external source maps? From some experimenting, I was also able to speed things up by removing react-material-ui SSR CSS generation (but this was before I discovered the above source map fix).

[tgdn]

I am also using semantic-ui-react throughout my project, and I am also affected by the extremely slow build times since I upgraded to Next@5. I will try your solution as soon as I can. I hope it works.
Thank you.

[plag]

@JonAbrams YES YES YES!! Thank you! Looks like source maps was reason of slowdown. 4.2.3 uses cheap-module-inline-source-map, version >=5 use source-map. Change it back makes SSR fast as before.

[albinekb]

I can confirm cheap source maps shaved about 5 seconds of all my page loads in dev!

@timneutkens is working on changing over to the cheap-module-source-map in here https://github.com/zeit/next.js/pull/4156/files#diff-0f2f34c098f5954f99483c9bd61e439dR124 🎉

[bryandowning]

This sourcemap change drastically improved hot reloading speeds for me (although page builds still take a while). I set my devtool option to eval for dev. I figure I'll just change it back when I need to debug.

For reference, here's the docs for this particular piece of webpack magic: https://webpack.js.org/configuration/devtool

[iaincollins]

To confirm, I am no longer seeing this in [email protected]

Thank you @timneutkens and everyone else who worked on this. 🎉

[msand]

I'm still seeing 80-200 second HMR on the client with the latest version and everything back up to https://github.com/zeit/next.js/commit/e093441bad588e98765a05df90f76f75283eda07
Before that (4.4.0-canary.3) it's really fast. Resolving react-hot-loader to 3.1.1 with Next 5.0.0-universal-alpha.14 is also fast, and Next 6.0.3 with
"resolutions": { "react-hot-loader": "4.2.0" },
Seems to work well again. Is anything keeping an upgrade to 4.2.0 back? @timneutkens

[msand]

To clarify, if I close the tab before the hmr starts, and reopen it, it loads within seconds. If I wait until "Checking for updates on the server..." the browser freezes for at least one minute, often two minutes. I might be able to produce a minimal reproduction with some effort.

[spiceboi]

edit: While the tweaks I made below helped, I'd still get stuck. Found this: https://github.com/angular/angular-cli/issues/5775 and think Terser just wants all my memory and all my cores, exacerbated in a CircleCI multi-stage build container.

For @Attidd and anyone else who landed here trying to figure out why their build is taking an extremely long time with semantic-ui-react/ semantic-ui, I realized that ultimately my issue was url-loader and using base64 png's with the their css url()'s for fonts, flag sprites, etc. My build step would be stuck at TerserPlugin for minutes, lock up my computer, and take 10x as long in CircleCI.

Ultimately I removed url-loader and configured my custom semantic-ui build to reference fontawesome assets from cdnjs.

[barrard]

I was making the silly mistake of not ignoring the next build files and nodemon was restarting over and over and resulted in long loading time. Now im happy to report hot-reloading only takes a few seconds

{   
  "ignore": ["next_app"] 
}