[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 🙏

timneutkens · 2024-08-20T19:00:07Z

@talglobus This look suspicious 😄

Besides that seeing a lot of missing time spent, same as with @Kashish280598's trace, which indicates webpack customization, however there's no next.config.js included so can't verify that.

talglobus · 2024-08-20T22:26:47Z

@timneutkens

@talglobus This look suspicious 😄

Besides that seeing a lot of missing time spent, same as with @Kashish280598's trace, which indicates webpack customization, however there's no next.config.js included so can't verify that.

Here's our next.config.js, our tsconfig.json, and our tailwind.config.js just for completeness. Really appreciate the insight, and let me know if there's anything we can offer in thanks, you're saving a huge amount of developer productivity for us!

timneutkens · 2024-08-21T09:01:40Z

@talglobus Looking at the config you're adding Sentry here: https://gist.github.com/talglobus/73cc83e1e136f1746af63b38cdb6c49a#file-next-config-js-L110 which adds a ton of overhead because Sentry's customization runs Rollup on all your code

kl-thamm · 2024-08-21T09:23:04Z

@talglobus Looking at the config you're adding Sentry here: https://gist.github.com/talglobus/73cc83e1e136f1746af63b38cdb6c49a#file-next-config-js-L110 which adds a ton of overhead because Sentry's customization runs Rollup on all your code

@timneutkens Does that mean we cannot use Sentry with Next? I am still trying to figure out what are just general performance improvements and what is a genuine next problem and how to fix that. This is another issue where its leaving it unclear to me. I have used Sentry in 4 different projects (one vue, python backend, react and now next) and yes - it does add some overhead to all these projects, but for all frontends I still have sub second compile times in dev and meanwhile up to 20 seconds with next. So this is not for scrubbing of the last few ms to get some more joy while developing, for many writing here, this is about saving hours in development time and getting a usable development environment.

Did you have a chance to look at this? #48748 (comment)
Is there any intention in addressing this on a higher level or have the issues been resolved from next's perspective and that is why you are resorting to individual advice? I am just a bit confused what the state and intention is with this issue.

Kashish280598 · 2024-08-21T11:44:19Z

@Kashish280598 As you can see in the screenshot below there's a lot of "missing time" on these recompiles, that indicates webpack customization could be accounting for all that missing time as that customization is not instrumented. Looking at the next.config.js it seems the only customization is adding the svgr/loader... so maybe it's that?

We had the following two customizations in our next.config.mjs for the Webpack configuration:

@svgr/webpack
file-loader for .mp3 files

Since we no longer use the 2nd file-loader customization, I removed it from the project as shown in this gist. However, I didn't notice any performance improvements after its removal. I’m wondering if @svgr/webpack might be causing the performance issues instead 🤔 ?

experimental: {
  turbo: {
    loaders: {
      ".svg": ["@svgr/webpack"],
    },
  },
},

Can you suggest some solution for this ? i found suggestion adding turbo like shown in the above. will that be helpful ?

codedpills · 2024-08-23T11:31:39Z

Hi @timneutkens, would appreciate if you could look into this trace if possible as it takes 20s+ to load the page on my dev server.

yuvalkarmi · 2024-08-23T13:00:58Z

Hey @timneutkens I actually ran trace-to-tree.mjs from the next.js project on my trace file and this is what I get. I don't know why my simple blog page is loading like 12K modules. I am using @mui/material but I do have:

  modularizeImports: {
    '@mui/icons-material': {
      transform: '@mui/icons-material/{{member}}',
    },
    '@mui/material': {
      transform: '@mui/material/{{member}}',
    },
    '@mui/lab': {
      transform: '@mui/lab/{{member}}',
    },
  },

Here's the output of trace-to-tree.mjs - would really appreciate understanding what's taking the longest here (and how you're doing that analysis).

Here's the tree.
blog-tree.txt

Would greatly appreciate your help in analyzing this!

brendanmorrell · 2024-08-27T18:46:56Z

Hello, @timneutkens . Here is the trace (including next config and trace.log drive link for turbopack).

I use a typescript custom server/i don't use next dev, which i assume is why NEXT_CPU_PROF=1 did not create anr profiling files, or i would have included those.

I also just switched to turbopack, which helped a little, but the compile times are still ~20s per page. I attempted to put as may relevant packages in optimizePackageImports but if anything that appeared to make it worse, and since i could not figure out from trace-to-tree what the actual offender/s may be, i just removed it since it was slowing things down.

I also do use tailwindcss, but i tried removing it entirely from the project, and i did not see any improvement, so that is likely not the problem. i am including that/postcss files as well though in case it helps

Any help is appreciated. Thank you!

grahamplace · 2024-08-27T22:10:25Z

@timneutkens following up on Chris's ask here (we work together) — would be great to get your analysis of our trace if you have time 🙏 Thanks!

#48748 (comment)

timneutkens · 2024-08-28T12:15:11Z

@brendanmorrell can you make sure to run Turbopack with next@canary, since you're on 14.2.x it's missing hundreds of fixes including performance improvements in Turbopack.

@grahamplace Similar for your app, it's on 14.2.4, but also the trace.log file is missing which means I can't inspect it.

CarlosVergikosk · 2024-08-28T13:11:40Z

We cannot update to canary since it requires react 19 and some packages (mdx.js) do not support it.

timneutkens · 2024-08-28T13:28:25Z

@CarlosVergikosk can you share a reproduction? We're running MDX in many places at Vercel and all our apps run on Next.js canary so maybe you're on an older version of MDX?

brendanmorrell · 2024-08-28T18:13:23Z

I also had avoided going to canary as I ran into a lof of errors with react 19 when i attempted to upgrade yesterday, but I can try to get it fully up to date and, send you the results in the next day or two. Thanks

grahamplace · 2024-08-29T19:19:04Z

We're in the same boat re: not being able to easily bump to Next canary due to lack of dependency support for React 19. If we can carve out time to try and work that out, we'll also make sure we send a trace.log file next time.

It might be helpful to add a callout about canary requiring React 19 in the instructions comment (and/or say explicitly you won't analyze any traces from Next v14), so folks better know what to expect:

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.

Thanks!

hexiaochen666 · 2024-08-30T08:52:48Z

Next canary due to lack of dependency support for React 19. My project must use React 18,how to solve it? o(╥﹏╥)o

zfm-dennisdisselhoff · 2024-09-02T14:04:00Z

In our codebase, we used an icon.tsx file to show browser icons depending on the environment (dev or prod). After deleting this file, we experienced a performance boost in the dev environment. We could decrease the compile time from 3-10s to 1-2s per page load.

I'm not sure if this is already known or if this is the right place to post our finding. Feel free to close or move my comment.

mxmzb · 2024-09-07T22:01:41Z

Hi @timneutkens, got the requested gist here: https://gist.github.com/mxmzb/804609e882a857e6a73a6a2bbcaa2dbc

Thank you for doing this 🙏

PS, could you maybe record a YouTube video showing what and how you're doing this?

codedpills · 2024-09-10T10:48:38Z

Hi @timneutkens, would appreciate if you could look into this trace if possible as it takes 20s+ to load the page on my dev server.

@timneutkens I was wondering if you had the time to take a look at the trace. Also, it would be great if you could show us how you're doing the analysis, so that we can run it also on our end. Thanks again.

T833357-SPARK · 2024-09-10T23:45:31Z

@timneutkens I would appreciate if you could look at this gist (containing trace, cpuprofile, and next.config).

We are hitting 40-50second compile times, and extremely slow hot-reloading. Has been a terrible dev experience and have tried bundle analysis and everything and can't find a culprit. But notice when "/" finally compiles it says its compiled (8000+ modules)

https://gist.github.com/T833357-SPARK/8f39dee84f972fb2a59ca3dd022f03a7

Thanks for the help

timneutkens · 2024-09-12T08:55:33Z

@mxmzb @codedpills I've recorded a video explaining how I looked at @T833357-SPARK's trace: https://www.youtube.com/watch?v=PGO2szAye7A hope it helps 👍

T833357-SPARK · 2024-09-15T22:32:26Z

Hey @timneutkens thanks for the video, I'm trying to reproduce running:

bun next internal turbo-trace-server ./next/trace

But I keep geting this error:
⚠ Turbopack trace server started. View trace at https://turbo-trace-viewer.vercel.app/ Unable to read trace file at "./next/trace", waiting...

I'm on next canary

Update: Still getting that error on pnpm, not sure how to get around it. I got around it once but its just keeps loading, devtools console logs say:

392-1dae64b243481d9b.js:71  WebSocket connection to 'ws://localhost:5747/' failed: 
t.createOrJoinSocket @ 392-1dae64b243481d9b.js:71
page-c1f8dd05c9d301b9.js:1 F12
392-1dae64b243481d9b.js:71  WebSocket connection to 'ws://localhost:5747/' failed:

Update 2: I tried giving an absolute file path instead
:~/the-application/apps/frontend $ pnpm next internal turbo-trace-server ~/the-application/apps/frontend/.next/trace ⚠ Turbopack trace server started. View trace at https://turbo-trace-viewer.vercel.app/ Trace file opened

Now it says "Trace file opened"

But devtools console still logs "WebSocket connection to 'ws://localhost:5747/' failed: " and I can't see the flamegraph

timneutkens · 2024-09-16T07:37:55Z

You passed ./next/trace but it should be .next/trace the folder that the file is located at is .next.

theogravity · 2024-09-16T17:34:56Z

In our codebase, we used an icon.tsx file to show browser icons depending on the environment (dev or prod). After deleting this file, we experienced a performance boost in the dev environment. We could decrease the compile time from 3-10s to 1-2s per page load.

I'm not sure if this is already known or if this is the right place to post our finding. Feel free to close or move my comment.

Are you using react-icons? Even though the next.js team says it should be dealt with via an internal optimizePackageImports rule, I didn't see any improvements in loading times for it. Replacing react-icons with the icon library we used from it removed around 40s of initial startup time for us on next.js 15 RC.

There needs to be an article / perf guide around large barrel packages (packages that have a ton of exports in their main entrypoint) and advise that you do a direct import to the component if possible to help with these issues.

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

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

Sign in to view

This comment was marked as resolved.

Sign in to view

This comment was marked as off-topic.

Sign in to view

theogravity mentioned this issue Sep 16, 2024

[perf] Export theme.ts / create-theme directly themesberg/flowbite-react#1489

Open

[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

timneutkens commented Aug 20, 2024

talglobus commented Aug 20, 2024

timneutkens commented Aug 21, 2024

kl-thamm commented Aug 21, 2024

Kashish280598 commented Aug 21, 2024

codedpills commented Aug 23, 2024

yuvalkarmi commented Aug 23, 2024 • edited Loading

This comment was marked as spam.

This comment was marked as resolved.

This comment was marked as off-topic.

brendanmorrell commented Aug 27, 2024 • edited Loading

grahamplace commented Aug 27, 2024

timneutkens commented Aug 28, 2024

CarlosVergikosk commented Aug 28, 2024 • edited Loading

timneutkens commented Aug 28, 2024

brendanmorrell commented Aug 28, 2024

grahamplace commented Aug 29, 2024 • edited Loading

hexiaochen666 commented Aug 30, 2024

zfm-dennisdisselhoff commented Sep 2, 2024 • edited Loading

mxmzb commented Sep 7, 2024 • edited Loading

codedpills commented Sep 10, 2024

T833357-SPARK commented Sep 10, 2024 • edited Loading

timneutkens commented Sep 12, 2024

T833357-SPARK commented Sep 15, 2024 • edited Loading

timneutkens commented Sep 16, 2024

theogravity commented Sep 16, 2024 • edited Loading

theogravity commented Sep 16, 2024 • edited Loading

T833357-SPARK commented Sep 18, 2024

T833357-SPARK commented Sep 19, 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

yuvalkarmi commented Aug 23, 2024 •

edited

Loading

brendanmorrell commented Aug 27, 2024 •

edited

Loading

CarlosVergikosk commented Aug 28, 2024 •

edited

Loading

grahamplace commented Aug 29, 2024 •

edited

Loading

zfm-dennisdisselhoff commented Sep 2, 2024 •

edited

Loading

mxmzb commented Sep 7, 2024 •

edited

Loading

T833357-SPARK commented Sep 10, 2024 •

edited

Loading

T833357-SPARK commented Sep 15, 2024 •

edited

Loading

theogravity commented Sep 16, 2024 •

edited

Loading

theogravity commented Sep 16, 2024 •

edited

Loading