20

I've investigated both the Next JS documentation as well as similar questions like Slow page build time in development with Next.js and TypeScript (which is TypeScript specific - this question concerns JavaScript and does not involve compiling TypeScript)

I am using next.js 10.0.9 and after running next, my app takes around 50 seconds to build and begin responding to HTTP requests.

After making a change, it takes another 12 seconds to rebuild. This seems much slower compared to other popular JS frameworks.

More detail:

  • npm run dev simply runs next and next takes around 50 seconds to become responsive (just after the compiled successfully is printed.

This means tasks like git bisect to find where a bug was introduced are very slow, as next has to do a full 1 minute rebuild after checking out each commit.

$ npm run dev

> hl-alpha-frontend@1.0.0 dev /home/mike/Code/myapp/alpha/frontend
> next

ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info  - Loaded env from /home/mike/Code/myapp/alpha/frontend/.env.local
info  - Loaded env from /home/mike/Code/myapp/alpha/frontend/.env.development
info  - Loaded env from /home/mike/Code/myapp/alpha/frontend/.env
warn  - React 17.0.1 or newer will be required to leverage all of the upcoming features in Next.js 11. Read more: https://err.sh/next.js/react-version
Warning: Built-in CSS support is being disabled due to custom CSS configuration being detected.
See here for more info: https://err.sh/next.js/built-in-css-disabled

info  - Using external babel configuration from /home/mike/Code/myapp/alpha/frontend/babel.config.json
event - compiled successfully
event - build page: /
wait  - compiling...
event - compiled successfully
  • Making small changes to files requires around 12 seconds of compiling... watching the triangle before the page becomes responsive at compiled successfully.

How can I speed up next.js build times?

Updates

Running @next/bundle-analyzer helped - thanks @juliomalves - I can see we're loading all of react-heroicons (that's the big index.js in the picture) which ~I can easily fix with more specific imports.~ Update - this is now done though out the codebase

Old:

> import * as Icon from "@graywolfai/react-heroicons";

New:

import { BellOutline } from "@graywolfai/react-heroicons";

This has speed up my build times (after running next, the compiling task finishes faster). However my bundles still seem to be the same size.

mikemaccana
  • 110,530
  • 99
  • 389
  • 494
  • 2
    The first step would be to find out what's causing those lengthy compile times. What does your build size look like? – juliomalves Mar 22 '21 at 16:12
  • 1
    Good question @juliomalves! Loading /` and looking at the Network tab in devtools, the three largest JS files are `index.js` at 5.6 MB, `_app.js` at 3.5MB, `main.js` at 984K. Does Next have tools to analyse bundle size and work out where dependencies are used? – mikemaccana Mar 22 '21 at 16:46
  • 4
    I'd recommend using [`@next/bundle-analyzer`](https://www.npmjs.com/package/@next/bundle-analyzer) to analyse the bundles. – juliomalves Mar 22 '21 at 16:50
  • 2
    Thanks @juliomalves! I've done that and attached the output to the question along with some follow up questions to try and understand the output better. – mikemaccana Mar 22 '21 at 18:06
  • @juliomalves Yep I mentioned that in the updates to the question. Fixing it now. However I have some followup questions. – mikemaccana Mar 22 '21 at 18:19
  • 1
    Fixing those imports _should_ reduce the bundle size and remove redundancy. – juliomalves Mar 22 '21 at 19:13
  • @juliomalves I've changed all the imports to more specific imports, see the updated question. This seems to speed up build times however my bundle sizes remain the same. – mikemaccana Mar 23 '21 at 10:29

5 Answers5

15

I've faced the same issue with next.js version 12.1.5.

My problem was that I was forgetting the server npm run dev was still running - after closing npm run dev and running the build again the build completed in almost 3 minutes.

mikemaccana
  • 110,530
  • 99
  • 389
  • 494
Ahmed Ayman
  • 151
  • 1
  • 5
  • 3
    Good answer and welcome to Stack Overflow! I've tweaked your answer to fix the markdown a little but your answer helps others who may have the same cause. Have an upvote! – mikemaccana Jun 28 '22 at 08:09
4

This question is a few months old, but I'd recommend upgrading Next.js.

The most recent versions of Next.js (11, and 12) have large performance improvements to start-up time, hot reloading, and compilation. And they tend to be very backward-compatible.

Version 11 blog post: https://nextjs.org/blog/next-11

Version 12 blog post: https://nextjs.org/blog/next-12

Mike Cavaliere
  • 670
  • 6
  • 10
0

For me it worked by upgrading the NextJS version. I also updated few other libraries like dexie-js.

npm install next@latest react@latest react-dom@latest
satyam_naithani
  • 49
  • 1
  • 3
-1

I faced the same issue basically. In my case I just killed the port which it was running, to clean it up by using this command:

npx kill-port 3000
Marcel Dz
  • 2,321
  • 4
  • 14
  • 49
  • This seems like a copy of https://stackoverflow.com/a/72777871/123671 – mikemaccana Jun 28 '22 at 15:01
  • @mikemaccana I think you didn't understand or read the answer above, because then you wouldnt talk about a copy. – Marcel Dz Jun 29 '22 at 06:10
  • ports can't be killed, only apps listening on ports can. Killing the app is the same as the answer in the link. – mikemaccana Jun 29 '22 at 09:10
  • in my case it was a clear difference thats why i posted it here. – Marcel Dz Jun 29 '22 at 11:37
  • how is killing the app listening on a port different from killing an app with the keyboard? One might be signal interrupt versus terminate but they’re both sending a signal to an app to stop it running. – mikemaccana Jun 29 '22 at 11:40
  • In my case there were multiple processes on the given port which brought me to the same effect as the guy with the question canceling it in the terminal only killed the actively initialized connection in vscode. Killing the other processes which where active for example if you forget stopping your server multiple time weren’t effected. Using the command instead of solved my problem. It’s only an advice, if it is providing some people reading this the solution it’s perfectly fine for me mentioning my case – Marcel Dz Jun 29 '22 at 11:54
  • you can’t have multiple processes on the same port in Linux, MacOS and Windows. – mikemaccana Jun 29 '22 at 12:38
  • Im interested in your explanation then why the thread creator does have such performance issues. Because its also not possible having a 50+ second rebuild on a basic next.js server and 12+ seconds on reload by only fetching and posting using http requests if the next.js server process is running normally. I can only share my experience on this and for me it solved the issue. This post underlines what i'm saying: https://stackoverflow.com/questions/39322089/node-js-port-3000-already-in-use-but-it-actually-isnt It is possible that there is something else also running on the same port. – Marcel Dz Jun 29 '22 at 13:34
  • All the answers for that question are from people who assert there is a single process running on the port. See https://www.npmjs.com/package/kill-port - quoting "Kill process running on given port" - not "processes". or better yet, look up how sockets work! I assure you 1 process per port is how TCPIP works. Edit: apparently there's an odd exception on Windows, but that's all, see https://stackoverflow.com/questions/17212789/multiple-processes-listening-on-the-same-port – mikemaccana Jun 29 '22 at 13:41
-18

NextJS compile slow after I try test with pwa. You need clear data from application as the bellow to fix it!

enter image description here

Sam Nguyen
  • 13
  • 1
  • 1