Problems with turbopack in dev development being way too slow, taking 25 seconds for page to fully compile

[gustavotrapp]

Summary

I'm currently building a very complex page, which is essentially a dynamic dashboard builder, sort of like Grafana or Metabase. The page loads are taking forever, and with this page in specific, it takes a long time. But every single other page that we have in our application also takes a ridiculous amount of time. It takes anywhere from 15 seconds to, in this case, 25 seconds. When my machine is very slow, it can take up to a minute really, but in this case, it took 25 seconds, and the experience is complete trash. The dev server keeps restarting, and I'm just looking for a way of getting better performance. How can I optimize this? Is this really just a limitation? What can I do?

Yes I'm using Turbopack
Yes I've read https://nextjs.org/docs/app/guides/local-development
No I can't really share much code, but the compiled build of the page is approximately ~2.5MBs
Other pages are around ~500kBs

Video showing the turbopack-trace: https://www.loom.com/share/4e0aa5c58ea14bd8a03d892c5a85319e

Project setup

Our setup is essentially a monorepo with Turborepo and we have a apps/ folder which has just our Next.js application with another service that we have that's an internal service. Then in our packages we have our tRPC package, a db package and a few other utility packages. Essentially, what we do is we always compile our packages so that our typescript performance isn't bad when we use it in our Next.js app. Then we essentially just import it all as a private internal module.

Weird bugs

Additionally, I think it's important to mention that sometimes I have to restart my MacBook after developing for a long time because the HMR in hotreload just doesn't work anymore. I mean, I get a HMR error in the terminal saying that something failed, but I have no idea what, and it just doesn't work. The refresh doesn't work. I make a change, it doesn't reflect. It's extremely weird.

Additional information

Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 25.0.0: Wed Sep 17 21:41:39 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T8103
Available memory (MB): 8192
Available CPU cores: 8
Binaries:
Node: 20.19.5
npm: 10.9.2
Yarn: 1.22.22
pnpm: 10.7.1
Relevant Packages:
next: 16.0.1
eslint-config-next: N/A
react: 19.2.0
react-dom: 19.2.0
typescript: N/A
Next.js Config:
output: standalone

Example

I can't provide this because it's internal code from our organization.

[gustavotrapp]

No response, is the vercel team just pretending this doesn't happen with bigger projects, how am I supposed to trust Next.js as a product if it cant scale for my needs

[icyJoseph]

Hi, there has been a lot of reports and things happening around the release time (the auto discussion creation tool from Turbopack helps a lot but also pushes down some other items)

I'll take a look! From what we have seen though, most large projects do well. We are aware of some reports on OOM, and just earlier someone reported a page that renders for 2 minutes before crashing out. No obvious indication as to what happens there.

Let me take a look and I'll try to come back with more questions. I assume this is without cache components?

[icyJoseph]

Btw, you can try in canary now, bare in mind that it is still not a full release, next experimental-analyze --serve IIRC, and that'll output a map of the imports. I wonder if that'd give us more insight into what's happening here.

[gustavotrapp]

Hi, there has been a lot of reports and things happening around the release time (the auto discussion creation tool from Turbopack helps a lot but also pushes down some other items)

I'll take a look! From what we have seen though, most large projects do well. We are aware of some reports on OOM, and just earlier someone reported a page that renders for 2 minutes before crashing out. No obvious indication as to what happens there.

Let me take a look and I'll try to come back with more questions. I assume this is without cache components?

Yes we don't use cache components as we are in NextJS 15, also we don't intend on switching

Btw, you can try in canary now, bare in mind that it is still not a full release, next experimental-analyze --serve IIRC, and that'll output a map of the imports. I wonder if that'd give us more insight into what's happening here.

We are really dissapointed, this problem keeps getting worse, 3 weeks and we have added even more features to our page and now we consistently have to wait a whole 2 minutes in dev for first compile. Also we get extremely high next dev server instances (+10 GB of RAM) making the server restart, in turn making us wait 2 more minutes just to keep going.

We already use turbopack, and yeah its great, it's fast, but if my mac has 9 GB RAM just trying to run the thing what is the point?

[icyJoseph]

Did you install next@canary to use the analyzer?

Unfortunately, without a trace or any more info, it is really hard to infer anything here. Is this app processing JSON data, what kind libraries is it importing? Any chance there's circular imports?

[cbovis]

We suffer from the same issue and it's got me pulling my hair out on a daily basis.

I don't get forced restarts but have to restart often anyway because Turbopack often just refuses to incorporate the changes I've made with only a full restart doing the trick. If changes do get incorporated automatically then it's after a long delay (at least 30 seconds) but it seems to quickly devolve into just not incorporating changes.

The odd thing is that it feels like Turbopack just isn't responding to the changes. When a recompile does happen Turbopack will often tell me it took a couple of seconds or less to compile the change (makes sense for something like a simple button change) however in reality my waiting time was a lot longer. It also takes an excessive amount of time to respond to changes in next.config.ts, almost as though there's a file watcher or queuing issue going on.

I'm completely blind as to what's happening between hitting save on a file though and the changes maybe getting recompiled. Neither native Turbopack tracing nor experimental analyze features have provided any insight into what's going on. It would really help if there was an additional debug or verbose logging flag that could give some insight into Turbopack's internal processing.

Our application is large with a lot of dependencies so I can understand initial build times being slow (disk caching should help 🙏🏻) however incremental recompiles being slow is a mystery to me, especially on very simple component or css module changes. Rebuilding everything is often the better experience than trying to work with incremental builds but obviously has a massive detrimenal effect on DX, especially when refining something.

[icyJoseph]

If possible, https://nextjs.org/docs/app/guides/local-development#turbopack-tracing try this out, even better if we could take a look at it.

[cbovis]

Fuck a duck sideways I've had a breakthrough 😭

I was experiencing similar problems in Storybook powered by their NextJS Vite builder. Initial compile times pretty good but recompile times terrible. Similarly felt like it was lying to me on recompile time once the change was applied. We also usetsc --watch alongside next dev and that would respond very quickly to changes.

So I went down a path of thinking through whether this was related to watching for changes rather than recompiles...

I'm not an expert here but research suggests how tsc and Vite/Turbopack listen to file systems is very different. Tsc hooks in natively to MacOS's native bindings whereas Vite/Turbopack/etc use NodeJS file system watching which then uses native bindings. If NodeJS fails to use native bindings it'll silently fallback to polling.

Polling would line up with both Storybook (Vite) and Turbopack eventually recompiling but taking a god awful amount of time to do it. So I went down the path of trying to fix that problem... I did two things and unfortunately didn't isolate between changes however here they are for reference:

1. In Mac OS's Privacy and Security settings gave VS Code full disk access. I run commands via VS Code's terminal and it was suggested NodeJS can't use native FS events without that full access.
2. Went nuclear on the FS events log with sudo rm -rf /.fseventsd and then rebooted.

It's early days but this appears to have resolved my problems. I'm now seeing instant recompile of simple changes and HMR is working as expected.

@gustavotrapp I'd suggest spending a little time checking whether your problems are similar.

@icyJoseph it could be worth having this information in NextJS's local development docs page. Perhaps if Turbopack could somehow detect if fs watching is failing somehow and surface as a warning that would also be useful. Not sure how possible that is though. I'll check back after a few days to let you know how my experience has been!

[timneutkens]

Turbopack is written in Rust and does not use the Node.js watcher implementation. It uses fsevents when on macos and does not fall back to polling unless you explicitly opt-in to polling. Based on option 2 solving the problem for you it seems that fsevents was somewhat broken on your machine 🤔

[cbovis]

Got it, thanks for the extra context @timneutkens. Perhaps it is the second thing then. Odd that TSC would immediately respond though and Turbopack behaved like it was polling.

I've been actively working on some feature development since and HMR is still lightning fast so has held up so far 🤞

[cbovis]

Realised I can just revert the full disk access change to test against that. Saw no negative impact in turning it off and restarting so that leads me to think #2 must have been the actual fix and fsevents was corrupted in some way!

[gustavotrapp]

Updates:

We still have this issue, but I've generated an analyzed build so that maybe you can try and help me understand why these could potentially be so big in size:

client.html
edge.html
nodejs.html

Report and ReportMapGraph: This is a implementation of a chart using a geoJson of Brazil (maybe the geoJson is causing some slowness as that is a pretty big file?)

middleware.ts: This one I genuinely have no idea why it is that big, it's kinda of crazy

instrumentation.ts: It's our Sentry integration, should be nothing special, but somehow it is huge

@icyJoseph @timneutkens