[NEXT-1143] Dev mode slow compilation

[jeengbe]

⚠️ 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}

[joacub]

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

[jinojacob15]

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

[denu5]

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

[joacub]

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]

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

[jeengbe]

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]

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]

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]

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]

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]

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]

its slowing down the development..!

[vajajak]

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]

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]

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]

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]

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]

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

[Rykuno]

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]

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

Linked a bunch of related issues on this:
#50332

[JunkyDeLuxe]

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

[timneutkens]

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]

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 🙏

[maxiedaniels]

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

Experimental on 14, stable on 15 🙂

[mo-rally-dev]

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

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]

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]

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!):

1. 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!

2. 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.

[umashankar-pardhi-amla]

I'm still facing the same issue even after updating to "next": "14.2.12." This issue was first reported back in 2023, and it's frustrating that it still persists after a year.

While caching is working fine, I'm not sure what the focus is on—if the development environment isn't stable, what’s the point of using Next for development?

Can anyone assist me with this?

31 sec for compiling , also the page is also not refreshing

[kl-thamm]

We recently upgraded to next 15 and now use turbopack. We still have compile times ranging from 0.3 to 10s for first compiles on machine. Inside docker we have compile times of up to 300s with turobpack (compare to 10s with webpack). So this issue vercel/turborepo#4748 also certainly still is not resolved.

However turbopack is also not a solution on machine.
The "success stories" like #48748 (comment) still report horrendous compile times of up to 3 seconds on save and over 30 seconds initially.

[therealgilles]

I'm observing long delay between when a page is compiled and when it starts rendering:

[28.11.2024 18:09.14.728] [LOG]    ○ Compiling / ...
[28.11.2024 18:09.33.759] [LOG]   Source path: /.../src/app/globals.css
-- LOG START tailwindcss
[28.11.2024 18:09.33.760] [LOG]   Setting up new context...
[28.11.2024 18:09.33.964] [LOG]   Finding changed files: 24.909ms
[28.11.2024 18:09.34.799] [LOG]   Reading changed files: 824.456ms
[28.11.2024 18:09.34.805] [LOG]   Sorting candidates: 6.378ms
[28.11.2024 18:09.34.975] [LOG]   Generate rules: 176.403ms
[28.11.2024 18:09.34.979] [LOG]   Build stylesheet: 3.324ms
[28.11.2024 18:09.34.998] [LOG]   Potential classes:  4195
[28.11.2024 18:09.34.998] [LOG]   Active contexts:  1
[28.11.2024 18:09.35.139] [LOG]   JIT TOTAL: 1.456s
-- LOG END tailwindcss
[28.11.2024 18:09.42.720] [LOG]    ✓ Compiled / in 28.6s (2589 modules)
[28.11.2024 18:10.17.731] [LOG]   Render RootLayout
...
 GET / 200 in 72884ms

No idea how it can take 72sec. How can I find out what's taking so long?

Some details:

• I'm using NextJS 15.0.3.
• I'm not using Turbopack at this time, as I'm using tailwindcss with twin.macro and I don't think they are compatible. I enabled the DEBUG=1 tailwindcss config option and it's not taking long to process files.
• I've added optimizePackageImports for react-icons/[fa|go|hi2], and it helped some.

[kepman]

For everyone right now facing this issue, the culprit for me was tailwind css.

I found this sollution on stackoverflow: https://stackoverflow.com/a/70742247

My hot reaload times went from 10-30 seconds to < 1 second!
I now can save and instant see the changes in the browser again.

What it does is it seperates the tailwind compiler from the next js and runs as a seperate process.
Don't know the exact details how this works, but it works for me.

it basically creates a new file output.css which you can import in your global.css
and inside your global css you remove the:

@tailwind base;
@tailwind components;
@tailwind utilities;

and add it to the input.css

magically all the slow dev problems I've had are gone!

[Xentric925]

For everyone right now facing this issue, the culprit for me was tailwind css.

I found this sollution on stackoverflow: https://stackoverflow.com/a/70742247

My hot reaload times went from 10-30 seconds to < 1 second! I now can save and instant see the changes in the browser again.

What it does is it seperates the tailwind compiler from the next js and runs as a seperate process. Don't know the exact details how this works, but it works for me.

it basically creates a new file output.css which you can import in your global.css and inside your global css you remove the:

@tailwind base; @tailwind components; @tailwind utilities;

and add it to the input.css

magically all the slow dev problems I've had are gone!

@kepman
I am new to next, and I am using SASS so I haven't found an input.css file in my configuration

[kepman]

For everyone right now facing this issue, the culprit for me was tailwind css.
I found this sollution on stackoverflow: https://stackoverflow.com/a/70742247
My hot reaload times went from 10-30 seconds to < 1 second! I now can save and instant see the changes in the browser again.
What it does is it seperates the tailwind compiler from the next js and runs as a seperate process. Don't know the exact details how this works, but it works for me.
it basically creates a new file output.css which you can import in your global.css and inside your global css you remove the:
@tailwind base; @tailwind components; @tailwind utilities;
and add it to the input.css
magically all the slow dev problems I've had are gone!

@kepman I am new to next, and I am using SASS so I haven't found an input.css file in my configuration

You need to create the file..
I created a folder "tailwind" explicitly for the tailwind compiler create new file input.css in that folder and update your package.json in the scripts part:

"dev": "concurrently "next dev --turbo" "npx tailwindcss -i ./tailwind/input.css -o ./tailwind/output.css --watch""

[elbyss]

I had the same issue here, but I resolved it by using Turbopack. Previously, it took about 30 seconds, but now it's improved to 1 second. I'm using Next.js 15.0.3 and Docker.

[GBvanDam]

@timneutkens you can find my gist here and my trace.log here.

pnpx next@canary internal turbo-trace-server ./.next/trace.log
pnpx next@canary internal turbo-trace-server .next/trace.log

both don't seem to work for me, both commands in terminal finish with

⚠ Turbopack trace server started. View trace at https://turbo-trace-viewer.vercel.app/
Trace file opened
39% read (128/325 MB, 99 MB/s)
78% read (256/325 MB, 114 MB/s)
98% read (320/325 MB, 118 MB/s)

Initial read completed (325 MB, 2.7s)

but in the developer console of my browser I see

WebSocket connection to 'ws://localhost:5747/' failed: 
t.createOrJoinSocket

so I think I'm currently unable to review the logs myself. I am using "next": "^14.2.23", "pnpm@10.0.0" and "node@23.6.0". I guess it's because I'm using WSL Ubuntu-22.04, but can't get it to work. netstat -an | find "5747" results in

TCP    127.0.0.1:5747         0.0.0.0:0              LISTENING

[b-bot]

@timneutkens CPU Profile and trace here

Thought it was @tabler/icons-react but I see it's auto optimized now. Leaning towards Tailwind/NextUI as likely culprit, please assist.

[nickythorne]

Hi @timneutkens - we have an issue with cold start compilation times consistently taking 8-13+ seconds for our app. Incremental compilation takes far quicker (in the double digit milliseconds). Was going to raise a separate issue but felt this issue was better to report via.

We've generated the trace file and explored it via the trace viewer, however we can't drill in further so hoping you could provide some insight.

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 19:01:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10

Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.21
  pnpm: 7.33.4

Relevant Packages:
  next: 15.1.4
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3

Next.js Config:
  output: standalone

next.config.js and trace.log:
https://gist.github.com/nickythorne/d3fc32ff18a18a1defec9999891be2b5

trace-turbopack:
https://drive.google.com/file/d/1LBpcf2dPJXpnJXAEmd6sUeSjDIu66RpV/view?usp=sharing

For us seems like the module graph and client references phases are the culprits. Appreciate any help you can provide.

[nickthegroot]

Hey @timneutkens! We're also seeing cold start & edit issues causing major development slowdown. After going through this thread several times and trying to debug myself, would love some tips on what might be causing this.

Attached is a minimal (all instrumentation removed) next dev run. These timings are close to what we find in normal development.

• .next/trace
• CPU.main.1736831682817.cpuprofile

next dev

 ✓ Starting...
 ✓ Ready in 1042ms
 ○ Compiling /projects/[projectId] ...
 ✓ Compiled /api/admin/process-pgvector-file-folder-migration in 33.4s (7899 modules)
 GET /api/version 200 in 34664ms
 GET /api/version 200 in 14628ms
 GET /api/version 200 in 122ms
 POST /api/admin/process-pgvector-file-folder-migration 201 in 20149ms
 GET /api/version 200 in 35ms
 GET /api/version 200 in 136ms
 ✓ Compiled in 4.5s (7470 modules)
 POST /api/admin/hubspot-sync-job 200 in 25679ms
 GET /api/auth/jwt/jwks.json 200 in 388ms
 GET /projects/9304d3a0-59fd-4051-84b6-31caf39e2924 200 in 41328ms

We've often seen memory limit server restarts, in case that's relevant. For the trace above no such reboot occurred.

next info

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 20.18.1
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: 10.0.0
Relevant Packages:
  next: 14.2.22 // An outdated version detected (latest is 15.1.4), upgrade is highly recommended!
  eslint-config-next: 14.2.2
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.6.2
Next.js Config:
  output: N/A

Note we're unable to update to Next 15 due to package dependencies (spent multiple days on this). Turbopack also introduces some odd errors, so we didn't pursue that route much further beyond a half days work. If you expect these to have a big impact given the trace, I'm more then happy to report the issues and work through them!

[dhanushkac]

I tried Nextjs 15 with React 19. I have to say it is extremely slow and annoying to work with. It is taking more than 10 seconds to reflect a change. Not a very convenient experience honestly. This is slowing down development speed and productivity. Thinking about switching to Nextjs 14.

PS: I removed turbopack from next dev and seems like fine.

[kl-thamm]

My previous comment #48748 (comment) suggested to provide a systematic documentation on the problems and possible solutions.

@timneutkens It's unfortunate to see that this issue is not getting any attention anymore. I think the issue is two fold:

1. There are many tweaks that can and need to be done on a per-project base, but that are not really documented anywhere and that you need to figure out yourself from browsing this issue. There should be a dedicated, up-to-date page in the next docs and linked from the first post in this issue. With that, I guess that most project can get to a bearable development performance. Many here report that after putting much work into it, they reached multi second hot reloads, which at least makes it usable but is far from a smooth experience.
2. However: There are still performance issues within next and turbopack (for example within docker on Mac the performance is terrible, there has been an issue for that but it was marked as resolved). What would be important to know for those considering to switch to another framework: Is this something vercel acknowledges and is still working on? Is there an expected timeline?