[NEXT-1143] Dev mode slow compilation #48748

jeengbe · 2023-04-23T12:39:20Z

⚠️ this original post has been edited by @timneutkens to reflect this comment ⚠️

Changes in the past week

I've been investigating this over the past week. Made a bunch of changes, some make a small impact, some make a large impact. Here's a list:

Affects all applications
- Optimize next-app-loader resolving speed #50745
- Bail out of 404 page when favicon.ico doesn't exist #50795 -- If you don't have a favicon.ico
- Optimize Next.js bootup compilation #50379 -- If you have both pages and app and you're only working on app it will no longer compile the runtime for pages. Note: this shifts the compilation of the runtime to when you first open a page
Might not affect your app
- Improve compile time on large application #50792 -- This one I've only been able to reproduce on the Vercel website in development, it might make your compilation a lot faster (i.e. 50% faster for Vercel's website) but in most cases it likely won't affect your application.

You can try them using npm install next@canary.

Help Investigate

In order to help me investigate this I'll ideally need an application that can be run, if you can't provide that (I understand if you can't) please provide the .next/trace file.

If possible follow these steps which would give me the best picture to investigate:

npm install next@canary (use the package manager you're using) -- We want to make sure you're using the very latest version of Next.js which includes the fixes mentioned earlier.
rm -rf .next
start development using the NEXT_CPU_PROF=1 and NEXT_TURBOPACK_TRACING=1 (regardless of if you're using Turbopack, it only affects when you do use Turbopack) environment variable. E.g.:
- npm: NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 npm run dev
- yarn: NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 yarn dev
- pnpm: NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 pnpm dev
Wait a few seconds
Open a page that you're working on
Wait till it's fully loaded
Wait a few seconds
Make an edit to a file that holds a component that is on the page
Wait for the edit to apply
Wait a few seconds
Make another edit to the same file
Wait a few seconds
Exit the dev command (ctrl+c)
Upload the CPU traces put in the root of the application directory to https://gist.github.com
Upload the .next/trace file to https://gist.github.com -- Please don't run trace-to-tree yourself, as I use some other tools (e.g. Jaeger) that require the actual trace file.
If you're using Turbopack upload the .next/trace.log as well, if it's too large for GitHub gists you can upload it to Google Drive or Dropbox and share it through that.
Upload next.config.js (if you have one) to https://gist.github.com
Share it here

Known application-side slowdowns

To collect things I've seen before that cause slow compilation as this is often the root cause:

If you're on Windows, disable Windows Defender, it's a known cause of extreme slowdowns in filesystem access as it sends each file to an external endpoint before allowing to read/write
Filesystem slowness overall is what we've seen as the cause of problems, e.g. with Docker
react-icons, material icons, etc. Most of these libraries publish barrel files with a lot of re-exports. E.g. material-ui/icons ships 5500 module re-exports, which causes all of them to be compiled. You have to add modularizeImports to reduce it, here's an example: long compile times locally - along with "JavaScript heap out of memory" since upgrade to NextJS 13 #45529 (comment)
Custom postcss config, e.g. tailwindcss with a content setting that tries to read too many files (e.g. files not relevant for the application)

This and other slowdown reports are currently the top priority for our team. We'll continue optimizing Next.js with webpack where possible.
The Turbopack team is currently working on getting all Next.js integration tests passing when using Turbopack as we continue working towards stability of Turbopack.

Original post

Verify canary release

I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
    Binaries:
      Node: 18.13.0
      npm: 8.19.3
      Yarn: 1.22.18
      pnpm: 7.30.5
    Relevant packages:
      next: 13.3.1
      eslint-config-next: 13.3.1
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue

https://github.com/DigitalerSchulhof/digitaler-schulhof

To Reproduce

Note that I have been unable to replicate this issue in a demo repository.

Describe the Bug

The issue is that Next.js is generally slow in dev mode. Navigating to new pages takes several seconds:

[next] ready - started server on 0.0.0.0:3000, url: http://localhost:3000
[next] info  - Loaded env from /home/jeengbe/dsh/digitaler-schulhof/.env
[next] warn  - You have enabled experimental feature (appDir) in next.config.js.
[next] warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.
[next] info  - Thank you for testing `appDir` please leave your feedback at https://nextjs.link/app-feedback
[next] event - compiled client and server successfully in 1574 ms (267 modules)
[next] wait  - compiling...
[next] event - compiled client and server successfully in 219 ms (267 modules)
[next] wait  - compiling /(schulhof)/Schulhof/page (client and server)...
[next] event - compiled client and server successfully in 3.6s (1364 modules)
[next] wait  - compiling /(schulhof)/Schulhof/(login)/Anmeldung/page (client and server)...
[next] event - compiled client and server successfully in 1920 ms (1411 modules)
[next] wait  - compiling /api/schulhof/auth/login/route (client and server)...
[next] event - compiled client and server successfully in 625 ms (1473 modules)
[next] wait  - compiling /(schulhof)/Schulhof/Nutzerkonto/page (client and server)...
[next] event - compiled client and server successfully in 1062 ms (1482 modules)
[next] wait  - compiling /(schulhof)/Schulhof/Nutzerkonto/Profil/page (client and server)...
[next] event - compiled client and server successfully in 1476 ms (1546 modules)
[next] wait  - compiling /(schulhof)/Schulhof/Nutzerkonto/Profil/Einstellungen/page (client and server)...
[next] event - compiled client and server successfully in 2.1s (1559 modules)

The only somewhat reasonable time would be 600ms for the API route /api/schulhof/auth/login/route, even though that is still quite a lot slower than what it should be given its size.

It also doesn't look right to compile ~1500 modules for each page, as most of them should be cached. The pages are not very different.

Even an empty API route takes several hundreds of ms. The following example contains solely type exports:

[next] wait  - compiling /api/schulhof/administration/persons/persons/settings/route (client and server)...
[next] event - compiled successfully in 303 ms (107 modules)

I am not exactly sure how to read trace trees, but what stands out is that there are (over multiple runs) several entry next-app-loader that take 2+ seconds to complete:

│  │  ├─ entry next-app-loader?name=app/(schulhof)/Schulhof/page&page=/(schulhof)/Schulhof/page&appPaths=/(schulhof)/Schulhof/page&pagePath=private-next-app-dir/(schulhof)/Schulhof/page.tsx&appDir=/home/jeengbe/dsh/digitaler-schulhof/app&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&rootDir=/home/jeengbe/dsh/digitaler-schulhof&isDev=true&tsconfigPath=tsconfig.json&assetPrefix=&nextConfigOutput=! 1.9s

Find both dev and build traces here: https://gist.github.com/jeengbe/46220a09846de6535c188e78fb6da03e

Note that I have modified trace-to-tree.mjs to include event times for all events.

It also seems unusual that none of the modules have child traces.

Expected Behavior

Initial load and navigating should be substantially faster.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_{From SyncLinear.com | NEXT-1143}

The text was updated successfully, but these errors were encountered:

joacub · 2023-04-24T18:20:54Z

same here, and in docker env is even worse, seems like is processing same files over and over without caching them.

jinojacob15 · 2023-04-25T03:57:46Z

Same for me also dev env ,navigating to different pages via link component is pretty slow

denu5 · 2023-04-25T17:28:59Z

+1 its same here, hitting the page first time seems fine but routing via links gets stuck

joacub · 2023-04-25T17:34:00Z

last canary version has a better cold build times improvements, still slow like 2-5 seconds (in docker env) waiting but much better

the version im talking about is 13.3.2-canary.6

denu5 · 2023-05-02T09:02:10Z

Hey, @jeengbe there have been some patch updates (13.3.1 -> 13.3.4) did it improve for you?

jeengbe · 2023-05-02T17:42:47Z

Hi @denu5,

unfortunately, I can't report any real performance changes since I opened this issue.

You might want to check out the above linked issue in the TypeScript repo though - might be related.

joacub · 2023-05-02T17:50:57Z

As @jeengbe mention there is no performance improvement, there is also a lot of I/O I don’t know why, one request gets pretty much like 1gb-2gb of io. And it is very slow.

jeengbe · 2023-05-02T18:07:49Z

As @jeengbe mention there is no performance improvement, there is also a lot of I/O I don’t know why, one request gets pretty much like 1gb-2gb of io. And it is very slow.

Unfortunately, I can't confirm this for my case

joacub · 2023-05-02T18:18:30Z

As @jeengbe mention there is no performance improvement, there is also a lot of I/O I don’t know why, one request gets pretty much like 1gb-2gb of io. And it is very slow.

Unfortunately, I can't confirm this for my case

That’s pretty good, in my case there is a lot of I/O, maybe is because I’m using material-ui but I think is too much even though.

jeengbe · 2023-05-02T18:22:30Z

As @jeengbe mention there is no performance improvement, there is also a lot of I/O I don’t know why, one request gets pretty much like 1gb-2gb of io. And it is very slow.

Unfortunately, I can't confirm this for my case

That’s pretty good, in my case there is a lot of I/O, maybe is because I’m using material-ui but I think is too much even though.

Possibly, it would align with what your trace shows: #48407 (comment)

langfordG · 2023-05-04T23:19:59Z

I see that slow route changes in dev mode are showing a '[Fast Refresh] rebuilding' message in the browser console. Sometimes it performs a full page reload when changing routes even if no files have been edited.

AsathalMannan · 2023-05-15T13:46:50Z

its slowing down the development..!

vajajak · 2023-05-21T10:06:21Z

Having the same issue here, in the Docker environment it's come to a point where it's almost unusable, and sometimes I even have to do a hard reload, after waiting too long for navigation. This is the case both with component from next/navigation, as with the router.push (useRouter hook imported from next/navigation). We're using Next.js 13.4.2.

joacub · 2023-05-22T00:50:15Z

Having the same issue here, in the Docker environment it's come to a point where it's almost unusable, and sometimes I even have to do a hard reload, after waiting too long for navigation. This is the case both with component from next/navigation, as with the router.push (useRouter hook imported from next/navigation). We're using Next.js 13.4.2.

same here, it is almost not usable in dokcer enviorements, but also outside docker is very slow, something is not working nice. this is painfully slow.

JoshApp · 2023-05-27T07:22:54Z

Yeah same for me. I used to remote develop inside our k8s cluster but dev --turbo is super slow inside a container and causes my health check endpoint to sigkill it regularly.

The whole app router is super slow when containerized in Dev mode.

It works perfectly fine when I run both on my local machine and connect it via reverse proxy. This way it's faster than the old setup (which was not significantly faster before) and takes advantage of preloading pages via next/link. I see inconsistencies in caching too where it's a mix of instant navigation or long builds (around 3.5k modules for some things) around 2-10 sec.

Also there is this weird thing happening that a page compiles just fine and then later it grinds to a halt being stuck in waiting for compiling forever until the pod is crashed.

Rykuno · 2023-05-27T18:18:46Z

I love next, but this is a complete show stopper. Sometimes it takes 10+ seconds outside of docker for me on a Mac M2 to navigate one page.

This is insane.

joacub · 2023-05-27T18:23:59Z

I love next, but this is a complete show stopper. Sometimes it takes 10+ seconds outside of docker for me on a Mac M2 to navigate one page.

This is insane.

Yep even more I get sometimes 50 seconds in a simple page, that’s because is also building other things related to that in pralllel I guess.

not even outside docker, i just make a test to work outside docker and timing is exactly the same no difference…. Is getting slower and slower

joacub · 2023-05-27T18:26:23Z

Btw webpack lazy building cold is faster than turbopack 🙂 by far

Rykuno · 2023-05-27T18:27:32Z

Btw webpack lazy building cold is faster than turbopack 🙂 by far

Yes! I'm surprised this is not more prevalent as an issue atm; unless turbo will somehow fix all of this in 13.5 and they're waiting to address it.

What configs do you have for the faster webpack builds? I've tried quite a bit and can't lower my built time by much. I need a temporary fix for this ASAP :(

oalexdoda · 2023-05-29T11:41:17Z

A month later no updates on this? Makes development on appDir absolutely impossible. @timneutkens ?

Linked a bunch of related issues on this:
#50332

JunkyDeLuxe · 2023-06-02T07:36:16Z

I confirm that next app dir on dev mode and dynamic routing are very very slow on docker now

timneutkens · 2023-06-06T10:23:44Z

Changes in the past week

I've been investigating this over the past week. Made a bunch of changes, some make a small impact, some make a large impact. Here's a list:

Affects all applications
- Optimize next-app-loader resolving speed #50745
- Bail out of 404 page when favicon.ico doesn't exist #50795 -- If you don't have a favicon.ico
- Optimize Next.js bootup compilation #50379 -- If you have both pages and app and you're only working on app it will no longer compile the runtime for pages. Note: this shifts the compilation of the runtime to when you first open a page
Might not affect your app
- Improve compile time on large application #50792 -- This one I've only been able to reproduce on the Vercel website in development, it might make your compilation a lot faster (i.e. 50% faster for Vercel's website) but in most cases it likely won't affect your application.

You can try them using npm install next@canary.

Help Investigate

In order to help me investigate this I'll ideally need an application that can be run, if you can't provide that (I understand if you can't) please provide the .next/trace file.

If possible follow these steps which would give me the best picture to investigate:

npm install next@canary (use the package manager you're using) -- We want to make sure you're using the very latest version of Next.js which includes the fixes mentioned earlier.
rm -rf .next
start development using the NEXT_CPU_PROF=1 environment variable. E.g.:
- npm: NEXT_CPU_PROF=1 npm run dev
- yarn: NEXT_CPU_PROF=1 yarn dev
- pnpm: NEXT_CPU_PROF=1 pnpm dev
Wait a few seconds
Open a page that you're working on
Wait till it's fully loaded
Wait a few seconds
Make an edit to a file that holds a component that is on the page
Wait for the edit to apply
Wait a few seconds
Make another edit to the same file
Wait a few seconds
Exit the dev command (ctrl+c)
Upload the CPU traces put in the root of the application directory to https://gist.github.com
Upload the .next/trace file to https://gist.github.com -- Please don't run trace-to-tree yourself, as I use some other tools (e.g. Jaeger) that require the actual trace file.
Share it here

Known application-side slowdowns

To collect things I've seen before that cause slow compilation as this is often the root cause:

If you're on Windows, disable Windows Defender, it's a known cause of extreme slowdowns in filesystem access as it sends each file to an external endpoint before allowing to read/write
Filesystem slowness overall is what we've seen as the cause of problems, e.g. with Docker
react-icons, material icons, etc. Most of these libraries publish barrel files with a lot of re-exports. E.g. material-ui/icons ships 5500 module re-exports, which causes all of them to be compiled. You have to add modularizeImports to reduce it, here's an example: long compile times locally - along with "JavaScript heap out of memory" since upgrade to NextJS 13 #45529 (comment)
Custom postcss config, e.g. tailwindcss with a content setting that tries to read too many files (e.g. files not relevant for the application)

This and other slowdown reports are currently the top priority for our team. We'll continue optimizing Next.js with webpack where possible.
The Turbopack team is currently working on getting all Next.js integration tests passing when using Turbopack as we continue working towards stability of Turbopack.

timneutkens · 2023-06-06T13:52:00Z

Changed the initial post in this issue to reflect my reply above in order to ensure people see it as the first thing when opening the issue. I'm going to close the duplicate issues reporting similar slowdowns in favor of this one.

I'll need help from you all to ensure this thread doesn't spiral in "It is slow" comments that are not actionable when e.g. without traces / reproduction / further information. Thank you 🙏

theogravity · 2024-09-16T18:54:08Z

I added the following to my scripts to troubleshoot (Next.js 15 RC):

{
  "scripts": {
    "build": "next build",
    "dev": "next dev",
    "prod": "next start",
    "dev:trace": "NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 next dev",
    "view-trace": "next internal turbo-trace-server ./.next/trace",
  },
}

Run dev:trace and let it load up to the page where you're trying to troubleshoot load times, then kill the server, then run view-trace to see the flamegraph.

One thing to note though that the flamegraph didn't feel anywhere near accurate (it was claiming that react-icons consumed only 10s, but it was in reality around 40s for us. However, the data was enough for us to investigate.

T833357-SPARK · 2024-09-18T23:17:00Z

next internal tur

I've fixed it and rerun a few times with bun next internal turbo-trace-server ./.next/trace and also bun next internal turbo-trace-server .next/trace

I still just get an infinite loading screen, WebSocket connection to 'ws://localhost:5747/' failed:

Figured it out though - I'm running in a Cloud9 instance. I tried running it locally and it works!

T833357-SPARK · 2024-09-19T01:25:07Z

Okay switching to --turbo has the compile times down to ~25 seconds, and faster hmr. Any way to further shave off time?

jotai-devtools is taking 1 second, mui is taking 1 second etc

wang-h · 2024-09-22T10:57:58Z

Big thanks to that bro whose answer got folded! I wasted a whole day on this. Ended up fixing it by switching from Webpack to Turbopack with this VSCode setup.

It finally works now!

What a rough day... Hope this helps someone else! Oh, and I’m using the new App Router, by the way!

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  "version": "0.2.0",
  "configurations": [  
    {
     "name": "Next.js: debug server-side",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev --turbo", //"npm run dev -- --turbo" any difference?
      "sourceMaps": true,
      "sourceMapPathOverrides": {
         "/turbopack/[project]/*": "${webRoot}/*"
      }
    },
    {
      "name": "Next.js: debug client-side",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}",
      "sourceMaps": true,
      "sourceMapPathOverrides": {
         "/turbopack/[project]/*": "${webRoot}/*"
      }

    }, 
    {
      "name": "Next.js: debug full stack",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev",
      "skipFiles": ["<node_internals>/**"],
      "sourceMaps": true,
      "sourceMapPathOverrides": {
        "/turbopack/[project]/*": "${webRoot}/*"
      },
      "serverReadyAction": {
        "action": "debugWithChrome",
        "killOnServerStop": true,
        "pattern": "- Local:.+(https?://.+)",
        "uriFormat": "%s",
        "webRoot": "${workspaceFolder}"
      }
    }
  ]
}

kavinvalli · 2024-09-24T21:31:50Z

Hey @timneutkens, https://github.com/helicone/helicone - we've been experiencing extremely slow dev compile times recently. Here's the trace: https://gist.github.com/kavinvalli/58946c70ed5d95265c13ac126356a8f1

Would be very helpful if you could take a look, since I'm not able to make out anything specific from pnpm next internal turbo-trace-server

maxiedaniels · 2024-09-26T18:06:31Z

Hey! Wondering if someone could look at my cpuprofile and trace? Link: https://gist.github.com/maxiedaniels/a949a901ce60bab38bee883e4c65c980

My pages take 5-10 seconds to load (from a refresh) in dev mode, but not in production. I've gone over all the normal causes and haven't found a solution. Thanks for the help!!

olafurns7 · 2024-09-30T14:00:20Z

Hi,

Using next 14.2.13 in turborepo, not using turbopack.

We're trying to utilize a generic page to handle CMS based routing, so we have:

app/src/[locale]/[[...slug]]/page.tsx

This has grown unsustainable as right now, even after attempts to trim down imports, we have around 4000 modules being logged during HMR, causing HMR to take ~2+ seconds.

.next/trace
cpu trace

We've tried all sorts of attempts to dynamically import components/files, but most of our code is not "client" components, so using lazy or next/dynamic really doesn't have any real effect on our structure.

We will probably resort to creating some hard coded level one navigation paths, but this is pretty strange behaviour and this issue was not this prominent in the pages router using a similar architechture.

mfrachet · 2024-10-07T12:03:15Z

@timneutkens sorry for the wild ping. If you still have time to check other projects with slow compilation, here's the actual situation for us:

For context

We use turbo (latest) and pnpm (8.7) for the monorepo
We use turbopack with the --turbo flag on next dev
We compiled all the barrel TS files on which we have control (the workspaces basically) to limit the time spent by TS
We use optimizePackageImports in the nextjs config to optimize tree shaking (our package graph looks good)
In this Google Drive folder, you'll find a video showing the issue, the trace file and the trace.log files

Questions

Is there a way we can read in details where the compiler is spending time? For instance "trying to compile lib XYZ and took X seconds" ? So that we can try to isolate the problem ahead of time?
What else could we try? (Detecting barrel files from external dependencies seems to be a bit annoying if done manually)

Thanks for your help and good luck with dealing with those types of issues (we know it's a pain) 🙏🏻 .

atsixian · 2024-10-08T04:41:51Z

Hey @timneutkens, NEXT_CPU_PROF=1 yarn dev gives this error every time. Do u know the possible causes?
Next.js version: 15.0.0-canary.179.

Cannot generate CPU profiling: Error [ERR_INSPECTOR_COMMAND]: Inspector error -32000: No recording profiles found

lauri865 · 2024-10-10T15:46:44Z

For us, --turbo is actually slower to compile initially than not using --turbo on [email protected]:

Without --turbo

✓ Ready in 1882ms
✓ Compiled /home in 2s (3590 modules)

With --turbo

✓ Ready in 769ms
✓ Compiled /home in 7.3s

Unfortunately HMR is a whole different story though, and --turbo makes that part a whole lot faster.

It would also help if the root route would be precompiled inline with next dev, because what's the use of having the server start up in 750ms, if the longest action has to be sequentially and manually triggered by the developer? The amount of time I'm losing to this every day is abysmal. Instead, if the root route would be prewarmed, it would make things go along much faster, evern for all sequential routes, as the main layout would be precompiled.

For the time being, we've hacked the instrumentation hook to trigger a fetch, which helps, but it boggles my mind that this is not the default behavior of a framework that claims to be all about developer experience.

instrumentation.ts

export const register =
  process.env.NODE_ENV === "development"
    ? () => {
        console.log("PRELOADING ROOT ROUTE");
        fetch(`http://localhost:${process.env.PORT}`);
      }
    : undefined;

gsusI · 2024-10-11T15:57:31Z

"If you're on Windows, disable Windows Defender, it's a known cause of extreme slowdowns in filesystem access as it sends each file to an external endpoint before allowing to read/write"

Installing malware might help, but I'm sure we want to focus on solutions that don't pose security risks to our systems.

woodytang · 2024-10-15T00:01:36Z

ubuntu 24.04 i7 6700, very slow, cpu usage is high when compiling

feedthejim · 2024-10-21T20:49:55Z

Hi everyone, if you're affected by dev perf issues, I'd like to share that Turbopack Dev is now stable in Next.js 15.

Please try it out today: https://nextjs.org/blog/next-15 and let us know how it's going.

oalexdoda · 2024-10-22T11:53:14Z

Hey team, any clue how to debug this? All was well last night, tried to upgrade to Next 15, didn't work, rolled back, and now it's stuck on compiling no matter what. Tried to delete .next, node_modules, etc.

It's just getting stuck on "compiling" no matter the page. No VPN or anything else.

Update: Seems to only happen when using turbo. Could it be a @sentry issue? Here's what shows when running the app without Turbo (which works):

blackhaj · 2024-10-24T14:31:06Z

Hey @timneutkens

Here is our CPU Trace our Next trace and our Next config

We have spent a lot of time removing barrel files from dependencies we control but page transitions are still very slow for us locally and we would love any pointers you have

maciesielka · 2024-10-25T20:22:29Z

Congrats on Turbopack Dev stability! We're still having problems with the dev experience, particularly with cold starts in both Webpack and Turbopack, so any pointers you have would be great!

I've followed the steps mentioned in this thread for both Webpack and Turbopack for comparison and have provided the info below:

webpack trace: gist
turbopack trace-turbopack: google drive (wasn't a format understood by Gist and is fairly large)
next config: gist
CPU trace: couldn't find this exactly, if someone could point me more specifically at it I'll provide it

Some other notes:

we are fully migrated to App Router
this is all tested on the just-launched Next 15 after following the migration guide

oalexdoda · 2024-10-26T00:34:10Z

Just wanted to drop this here, not sure if it helps - but it seems like most of the slowdown is due to RSC. Here's an example of a page getting loaded that seems to take 2-6 seconds multiple times. Not sure why it's doing that, but the overall route compiles in 3 seconds, followed by a long wait around RSC.

mischnic · 2024-10-28T09:42:10Z

@maciesielka It's taking a minute to process a single CSS file with some JS tool. Do you have a Tailwind/PostCSS config? Please share that as well then. (E.g. With Tailwind it's easy to accidentally include all of node_modules in its class scanning).

timneutkens · 2024-10-28T09:49:20Z

@oalexdoda the time shown for GET logs includes execution of your own code, the logs Compiled in are only Webpack/Turbopack processing.

@blackhaj can you try Turbopack first?

@maciesielka looks like it's one of these, given nearly all time is spent on Node.js execution:

Postcss customization (i.e. Tailwind?) -- Can't know this from the trace / files provided
- Maybe a bad Tailwind config, have a look at this: https://x.com/timneutkens/status/1783851267237781574
Webpack loaders added -- Looks like svgr

Edit: Seems Niklas already looked at the trace too 😄

maciesielka · 2024-10-28T13:49:32Z

@mischnic @timneutkens Thanks for your help! I've updated the gist from the previous post to include our tailwind and postcss configs, but I'll take a closer look given your notes above.

maciesielka · 2024-10-28T18:06:10Z

@mischnic @timneutkens Thanks for your help! I've updated the gist from the previous post to include our tailwind and postcss configs, but I'll take a closer look given your notes above.

This investigation was fruitful. Ignoring codgen-generated files that have no need for Tailwind from our tailwind.config.js made a massive improvement. 🚀

maxiedaniels · 2024-10-28T18:16:25Z

@timneutkens @mischnic Hey guys! Just wanted to point out my debug files again - Link: https://gist.github.com/maxiedaniels/a949a901ce60bab38bee883e4c65c980

My pages take 5-10 seconds to load (from a refresh) in dev mode, but not in production. I've gone over all the normal causes and haven't found a solution. Thanks for the help!!

timneutkens · 2024-10-29T08:38:38Z

@maxiedaniels now that Turbopack is stable for development I'd recommend trying that first, the trace for Turbopack will also be more complete than the webpack one.

maxiedaniels · 2024-10-29T20:56:21Z

@maxiedaniels now that Turbopack is stable for development I'd recommend trying that first, the trace for Turbopack will also be more complete than the webpack one.

Can I use the stable Turbopack on Next.js 14 or would I have to upgrade to 15?

timneutkens · 2024-10-30T14:19:34Z

Experimental on 14, stable on 15 🙂

mo-rally-dev · 2024-10-30T14:34:26Z

+1 on moving to Turbopack.

We recently bumped our Next version to 15, enabled Turbopack, and it changed everything! Next 14 helped a bit with the local dev experience but it was still painful. Upgrading to Next 15 with Turbopack finally resolved all of our pain points.

The upgrade was well worth the time, and I highly recommend it to anyone dealing with slow dev mode!

dazuaz · 2024-10-31T20:09:59Z

I experienced significant performance issues in my Next.js project, specifically when importing a non-treeshaking library at the top level of an action.ts file. After some testing, the only solution that worked for me was to:

Delete the import of the non-treeshakable library from the top-level action.ts file.
Move that library and related code closer to where it was actually needed in the project.
After making these adjustments, I noticed a substantial improvement in performance and more reasonable build and load times.

iraphaelfernandes · 2024-11-15T18:31:50Z

I’ve been testing some of the optimizations mentioned and would like to share my observations:

Compilation Improvement for Large Applications (#50792):

I tested this on a mid-sized app (approximately 1,000 modules in development mode) and saw about a 15% improvement in compilation speed. While not as dramatic as the reported 50% for the Vercel website, the improvement was noticeable and appreciated.
The change didn’t seem to affect smaller apps in my case, aligning with your notes.
404 Favicon Optimization (#50795):

This small but impactful change has made a difference in environments where favicon.ico is intentionally omitted. Previously, this triggered unnecessary fallback behavior in local development, which is now bypassed efficiently. Thank you for addressing this!
NEXT_CPU_PROF and NEXT_TURBOPACK_TRACING Feedback:

Following the steps provided, I captured .next/trace and CPU profile data for a small-to-medium app. I noticed the following:
The initial edit latency was slightly higher (~2.8 seconds) but dropped to ~1.5 seconds on subsequent edits.
If useful, I can upload the traces to a gist for further analysis. Please let me know.
Known Slowdown Factors:

The point about barrel files from libraries like Material-UI resonated with my experience. For example, after switching to modularizeImports for a Material-UI-heavy project, I observed a noticeable reduction in memory usage and compile times. Thanks for reiterating this tip!
Disabling Windows Defender on a colleague's setup resulted in significant I/O improvements.

melodyarcjason · 2024-11-18T15:39:42Z

I wanted to share my experience in case it is helpful for others - as I had to 'learn' some hard lessons - and hopefully this can save others the same pain. =)

TL;DR: Do not use next/dynamic on barrel file libraries (it defeats the optimization and creates unnecessary big module counts) and any server-side only packages - consider using experiemental.serverComponentsExternalPackages and making sure they are only called in files with 'use server' directive.

My situation: Fairly large production NextJS 14.2.15 App Router application. Experiencing major recompile times during development. Had my main workflow page - lots of components - taking 180-225s to recompile and load up. Terribly slow. Other pages - that I would consider normal size - roughly 20-40s compile times...

Outcome: My big page now has initial compile time of 35s and recompile times on save < 3s. All other pages have initial compile time of <5s and HMR triggers our very fast on small changes....

What fix MY issue (and might help you - I hope!):

Barrel file AND my own stupidity: We use @tabler/react-icons - and ended up adding this to the experimental.optimizePackageImports config which kind of helped, but not what others experienced. Then I realized in previous attempts to fix my issue I had applied next/dynamic to pull in my icons - HUGE MISTAKE! Dynamic was basically creating a chunk for each icon import I made of the whole tabler import - and well - yeah. Again, bad application of next/dynamic on my part. Removing all these dynamic imports gave me nearly 40% increase in compile/load times. BE CAREFUL with barrel files - and look at how you use them carefully!
The other ~30% performance gain I got was from applying experiemental.serverComponentsExternalPackages to the new @msal/node package we use for authentication work 'server' side. I also refactored my use of this library to make sure it was only used in files with the 'use server' directive The lesson - make sure if you have big libraries that are likely server-only - you put them in that context and use that ExternalPackages feature flag to keep them out of your overall bundling process.

jeengbe added the bug Issue was opened via the bug report template. label Apr 23, 2023

jeengbe mentioned this issue May 2, 2023

[TSServer] Very slow semantic diagnostics and completion (7s) microsoft/TypeScript#53609

Closed

timneutkens added the linear: next Confirmed issue that is tracked by the Next.js team. label May 10, 2023

timneutkens changed the title ~~Dev mode very slow navigation (Slow entry next-app-loader spans?)~~ [NEXT-1143] Dev mode very slow navigation (Slow entry next-app-loader spans?) May 10, 2023

timneutkens mentioned this issue Jun 6, 2023

App router slow performance when using dynamic route #50332

Closed

1 task

timneutkens changed the title ~~[NEXT-1143] Dev mode very slow navigation (Slow entry next-app-loader spans?)~~ [NEXT-1143] Dev mode slow navigation Jun 6, 2023

timneutkens changed the title ~~[NEXT-1143] Dev mode slow navigation~~ [NEXT-1143] Dev mode slow compilation Jun 6, 2023

This comment was marked as off-topic.

Sign in to view

[NEXT-1143] Dev mode slow compilation #48748

[NEXT-1143] Dev mode slow compilation #48748

Comments

jeengbe commented Apr 23, 2023 • edited by timneutkens Loading

Changes in the past week

Help Investigate

Known application-side slowdowns

Verify canary release

Provide environment information

Which area(s) of Next.js are affected? (leave empty if unsure)

Link to the code that reproduces this issue

To Reproduce

Describe the Bug

Expected Behavior

Which browser are you using? (if relevant)

How are you deploying your application? (if relevant)

joacub commented Apr 24, 2023

jinojacob15 commented Apr 25, 2023

denu5 commented Apr 25, 2023

joacub commented Apr 25, 2023 • edited Loading

denu5 commented May 2, 2023

jeengbe commented May 2, 2023

joacub commented May 2, 2023

jeengbe commented May 2, 2023 • edited Loading

joacub commented May 2, 2023

jeengbe commented May 2, 2023

langfordG commented May 4, 2023 • edited Loading

AsathalMannan commented May 15, 2023

vajajak commented May 21, 2023

joacub commented May 22, 2023

JoshApp commented May 27, 2023

Rykuno commented May 27, 2023

joacub commented May 27, 2023 • edited Loading

joacub commented May 27, 2023

Rykuno commented May 27, 2023 • edited Loading

oalexdoda commented May 29, 2023

JunkyDeLuxe commented Jun 2, 2023

timneutkens commented Jun 6, 2023 • edited Loading

Changes in the past week

Help Investigate

Known application-side slowdowns

timneutkens commented Jun 6, 2023

theogravity commented Sep 16, 2024 • edited Loading

T833357-SPARK commented Sep 18, 2024

T833357-SPARK commented Sep 19, 2024

wang-h commented Sep 22, 2024 • edited Loading

kavinvalli commented Sep 24, 2024 • edited Loading

maxiedaniels commented Sep 26, 2024

olafurns7 commented Sep 30, 2024

mfrachet commented Oct 7, 2024

atsixian commented Oct 8, 2024

lauri865 commented Oct 10, 2024 • edited Loading

gsusI commented Oct 11, 2024 • edited Loading

woodytang commented Oct 15, 2024

feedthejim commented Oct 21, 2024

oalexdoda commented Oct 22, 2024 • edited Loading

blackhaj commented Oct 24, 2024

maciesielka commented Oct 25, 2024 • edited Loading

oalexdoda commented Oct 26, 2024

mischnic commented Oct 28, 2024 • edited Loading

timneutkens commented Oct 28, 2024

maciesielka commented Oct 28, 2024 • edited Loading

maciesielka commented Oct 28, 2024 • edited Loading

maxiedaniels commented Oct 28, 2024

timneutkens commented Oct 29, 2024

maxiedaniels commented Oct 29, 2024

timneutkens commented Oct 30, 2024

mo-rally-dev commented Oct 30, 2024

dazuaz commented Oct 31, 2024

This comment was marked as off-topic.

iraphaelfernandes commented Nov 15, 2024

melodyarcjason commented Nov 18, 2024

jeengbe commented Apr 23, 2023 •

edited by timneutkens

Loading

joacub commented Apr 25, 2023 •

edited

Loading

jeengbe commented May 2, 2023 •

edited

Loading

langfordG commented May 4, 2023 •

edited

Loading

joacub commented May 27, 2023 •

edited

Loading

Rykuno commented May 27, 2023 •

edited

Loading

timneutkens commented Jun 6, 2023 •

edited

Loading

theogravity commented Sep 16, 2024 •

edited

Loading

wang-h commented Sep 22, 2024 •

edited

Loading

kavinvalli commented Sep 24, 2024 •

edited

Loading

lauri865 commented Oct 10, 2024 •

edited

Loading

gsusI commented Oct 11, 2024 •

edited

Loading

oalexdoda commented Oct 22, 2024 •

edited

Loading

maciesielka commented Oct 25, 2024 •

edited

Loading

mischnic commented Oct 28, 2024 •

edited

Loading

maciesielka commented Oct 28, 2024 •

edited

Loading

maciesielka commented Oct 28, 2024 •

edited

Loading