[NEXT-1143] Dev mode slow compilation

jeengbe commented 1 year ago

⚠️ 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
- https://github.com/vercel/next.js/pull/50745
- https://github.com/vercel/next.js/pull/50795 -- If you don't have a favicon.ico
- https://github.com/vercel/next.js/pull/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
- https://github.com/vercel/next.js/pull/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: https://github.com/vercel/next.js/issues/45529#issuecomment-1531912811
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 * [X] 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](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](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](https://synclinear.com) | [NEXT-1143](https://linear.app/vercel/issue/NEXT-1143/dev-mode-slow-compilation)}

joacub commented 1 year ago

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

jinojacob15 commented 1 year ago

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

denu5 commented 1 year ago

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

joacub commented 1 year ago

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 commented 1 year ago

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

jeengbe commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/vercel/next.js/issues/48407#issuecomment-1519044428

langfordG commented 1 year ago

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 commented 1 year ago

its slowing down the development..!

vajajak commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Rykuno commented 1 year ago

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 commented 1 year ago

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

Linked a bunch of related issues on this: https://github.com/vercel/next.js/issues/50332

JunkyDeLuxe commented 1 year ago

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

timneutkens commented 12 months ago

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
- https://github.com/vercel/next.js/pull/50745
- https://github.com/vercel/next.js/pull/50795 -- If you don't have a favicon.ico
- https://github.com/vercel/next.js/pull/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
- https://github.com/vercel/next.js/pull/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: https://github.com/vercel/next.js/issues/45529#issuecomment-1531912811
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 commented 12 months ago

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 🙏

JoshApp commented 12 months ago

@timneutkens is this applicable for turbopack too? it doesn't seem to generate a tracefile which it does using non turbo. I am happy to help with this issue

timneutkens commented 12 months ago

@JoshApp The trace file doesn't apply to Turbopack, for that we have different tooling but it's also still being optimized further, current focus for Turbopack is getting full compat with Next.js.

jeengbe commented 12 months ago

Thank you for addressing this @timneutkens!

However, the issue persists:

[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 (serverActions) 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.
// Initial load: (twice?)
[next] - event compiled client and server successfully in 178 ms (20 modules)
[next] - wait compiling...
[next] - event compiled client and server successfully in 101 ms (20 modules)
// Opening the page directly:
[next] - wait compiling /(schulhof)/Schulhof/(login)/Anmeldung/page (client and server)...
[next] - event compiled client and server successfully in 7.8s (1694 modules)
//                                                        ^^^^
[next] Warning: Each child in a list should have a unique "key" prop. See https://reactjs.org/link/warning-keys for more information.
// Making a change:
[next] - wait compiling...
[next] - event compiled client and server successfully in 958 ms (1684 modules)
// Making a change:
[next] - wait compiling...
[next] - event compiled client and server successfully in 524 ms (1684 modules)

Next Info:

    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: 8.6.0
    Relevant packages:
      next: 13.4.5-canary.6
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3

Trace: https://gist.github.com/jeengbe/f6b1bf54c04ab05bb40227c11fd90c7e

The issue can be replicated with the following repo: DigitalerSchulhof/digitaler-schulhof@82158e8 -> Copy .env.example -> pnpm dev -> Head to https://localhost/Schulhof/Anmeldung

tangzijun commented 11 months ago

trade-manager-website git:(main) ✗ pnpm dev

> trade-manager-website@0.1.0 dev /Users/tangzijun/CODE/_tgwm/trade-manager-website
> rm -f .env.local && next dev

- ready started server on 0.0.0.0:3000, url: http://localhost:3000
- info Loaded env from /Users/tangzijun/CODE/_tgwm/trade-manager-website/.env.development
- event compiled client and server successfully in 145 ms (20 modules)
- wait compiling...
- event compiled client and server successfully in 90 ms (20 modules)
- wait compiling /src/middleware (client and server)...
- event compiled successfully in 149 ms (43 modules)
- wait compiling /page (client and server)...

warn - As of Tailwind CSS v2.2, `lightBlue` has been renamed to `sky`.
warn - Update your configuration file to silence this warning.

warn - As of Tailwind CSS v3.0, `warmGray` has been renamed to `stone`.
warn - Update your configuration file to silence this warning.

warn - As of Tailwind CSS v3.0, `trueGray` has been renamed to `neutral`.
warn - Update your configuration file to silence this warning.

warn - As of Tailwind CSS v3.0, `coolGray` has been renamed to `gray`.
warn - Update your configuration file to silence this warning.

warn - As of Tailwind CSS v3.0, `blueGray` has been renamed to `slate`.
warn - Update your configuration file to silence this warning.
- event compiled client and server successfully in 10.4s (5949 modules)
- wait compiling /(subapp)/user/dashboard/page (client and server)...
- event compiled client and server successfully in 2.6s (6532 modules)
- wait compiling /(subapp)/user/dashboard/overview/page (client and server)...
- event compiled client and server successfully in 3.1s (7088 modules)
- wait compiling...
- event compiled client and server successfully in 2.2s (7100 modules)
- wait compiling...
- event compiled client and server successfully in 1428 ms (7100 modules)

mac m1 pro
next: 13.4.5-canary.7
next dev (no turbo)

Trace: https://gist.github.com/tangzijun/38ee02f3c2c8656e1d42c88dc257cdf0

manuelbarzi commented 11 months ago

here is my trace file. the delays continue. even with the latest canary versions. trace.txt

timneutkens commented 11 months ago

@manuelbarzi I'd like to run your application in order to investigate further. Are you using custom webpack config? Seeing 37 seconds of "dead time" (unaccounted for time in the trace). Because it's unaccounted for the only way to get more insights is running the app. Could you send me a dm https://twitter.com/timneutkens, alternatively you can contact Vercel support and mention this message then it'll find it to me as well.

timneutkens commented 11 months ago

@tangzijun yours is the same as what I shared earlier:

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: https://github.com/vercel/next.js/issues/45529#issuecomment-1531912811

In your case it's using @ant-design/icons and I'm seeing ~3000 trace lines referencing that module. Changing it to modularizeImports or manually only using the ones you need will reduce your build times tremendously.

manuelbarzi commented 11 months ago

@manuelbarzi I'd like to run your application in order to investigate further. Are you using custom webpack config? Seeing 37 seconds of "dead time" (unaccounted for time in the trace). Because it's unaccounted for the only way to get more insights is running the app. Could you send me a dm https://twitter.com/timneutkens, alternatively you can contact Vercel support and mention this message then it'll find it to me as well.

already sent you a DM @timneutkens ,)

SuttonJack commented 11 months ago

.next/trace gist

DM'd you on Twitter for private repo access

M1 Max - 64GB RAM

JunkyDeLuxe commented 11 months ago

Perhaps it's because dead imports like lodash, react-bootstrap or react-icons library I am using on my project. But I just finished to migrate my entire app to App NextJs directory (from pages ones), it's was very frustating to do so. My computer seems to be so slow. I am using MacbookPro m1 pro, 16GB RAM, with Docker-Desktop

My projet is updated with the last canary version from v13.4.5

Capture d’écran 2023-06-08 à 21 27 55

And this is my next-config file

/** @type {import('next').NextConfig} */
const path = require('path');
const { version } = require('./package.json');

const nextConfig = {
    images: {
        remotePatterns: [
            {
                protocol: 'https',
                hostname: '**.neo9.pro',
            },
            {
                protocol: 'https',
                hostname: '**.mousquetaires.com',
            },
        ],
    },
    env: {
        VERSION: version,
    },
    sassOptions: {
        includePaths: [path.join(__dirname, 'styles')],
    },
    modularizeImports: {
        'react-bootstrap': {
            transform: 'react-bootstrap/{{member}}',
        },
        'react-icons': {
            transform: 'react-icons/{{member}}',
        },
        lodash: {
            transform: 'lodash/{{member}}',
        },
    },
    async rewrites() {
        return [
            {
                source: '/web-api/:path*',
                destination: 'http://web-api:8080/:path*',
            },
        ];
    },
};

module.exports = nextConfig;

As u can see, there is some pages, I have to wait sometimes ten seconds before be able to navigate to other pages on my app directory

my trace file

What I can see, dunno if it's helping, The live reload is pretty quick. If I add a console.log('coucou') on a page.tsx file, this is the output

Capture d’écran 2023-06-08 à 21 38 38

But I decide to move to another page, where I didn't go before my dev working session, or without refreshing my web page, it's hudge, sometimes I have to wait 20 seconds ...

Perhaps it's come from DockerDesktop & Mac ... But with pages directory, I didn't have the problem Thanks for helping us ..

fabriciopirini commented 11 months ago

What I can see, dunno if it's helping, The live reload is pretty quick. If I add a console.log('coucou') on a page.tsx file, this is the output

But I decide to move to another page, where I didn't go before my dev working session, or without refreshing my web page, it's hudge, sometimes I have to wait 20 seconds ...

Same experience as @JunkyDeLuxe on a M1 Pro but not using Docker.

Trace

JunkyDeLuxe commented 11 months ago

I hope the problem don't come from React-bootstrap library ...

tomaszferens commented 11 months ago

here is a trace. It takes like ~15sec to compile:

[1] wait  - compiling...
[1] event - compiled client and server successfully in 16.5s (8099 modules)
[1] wait  - compiling...
[1] event - compiled client and server successfully in 10.8s (7772 modules)
^C[0] Gracefully stopping... (press Ctrl+C again to force)

tomas-c commented 11 months ago

Here's my trace (I also included next.config.js in the comments of the gist). Initial compile takes ~20s. Rebuild is around ~2s. Tested with 13.4.5-canary.9

jeengbe commented 11 months ago

It is very strange, though, that Next/webpack watch all node_module files and re-compile if changes are made to those. Is there maybe a caching issue? It could help to also include not just how many modules are affected in total ((8099 modules)), but also how many modules were re-compiled with a change (something like (8099 modules - 12 recompiled) assuming the file that triggered the recompilation has 12 dependents).

joacub commented 11 months ago

Perhaps it's because dead imports like lodash, react-bootstrap or react-icons library I am using on my project. But I just finished to migrate my entire app to App NextJs directory (from pages ones), it's was very frustating to do so. My computer seems to be so slow. I am using MacbookPro m1 pro, 16GB RAM, with Docker-Desktop

My projet is updated with the last canary version from v13.4.5

And this is my next-config file
/** @type {import('next').NextConfig} */
const path = require('path');
const { version } = require('./package.json');

const nextConfig = {
  images: {
      remotePatterns: [
          {
              protocol: 'https',
              hostname: '**.neo9.pro',
          },
          {
              protocol: 'https',
              hostname: '**.mousquetaires.com',
          },
      ],
  },
  env: {
      VERSION: version,
  },
  sassOptions: {
      includePaths: [path.join(__dirname, 'styles')],
  },
  modularizeImports: {
      'react-bootstrap': {
          transform: 'react-bootstrap/{{member}}',
      },
      'react-icons': {
          transform: 'react-icons/{{member}}',
      },
      lodash: {
          transform: 'lodash/{{member}}',
      },
  },
  async rewrites() {
      return [
          {
              source: '/web-api/:path*',
              destination: 'http://web-api:8080/:path*',
          },
      ];
  },
};

module.exports = nextConfig;
As u can see, there is some pages, I have to wait sometimes ten seconds before be able to navigate to other pages on my app directory

my trace file

What I can see, dunno if it's helping, The live reload is pretty quick. If I add a console.log('coucou') on a page.tsx file, this is the output

But I decide to move to another page, where I didn't go before my dev working session, or without refreshing my web page, it's hudge, sometimes I have to wait 20 seconds ...

Perhaps it's come from DockerDesktop & Mac ... But with pages directory, I didn't have the problem Thanks for helping us ..

If pages were working faster why app dir not? They should perform the same or even better…

OlegLustenko commented 11 months ago

Related #46884

FrozenHearth commented 11 months ago

I mostly experience this when using clerk.dev with Next 13.4 on a Mac M2 Pro. And sometimes without using any external packages.

gokulkrishh commented 11 months ago

Same here, trying to re-write expense.fyi from pages to app dir. Development is super slow for app dir.

timneutkens commented 11 months ago

I'm going to keep this issue actionable comment only so please do not pile on with comments that do not include traces / performance profiles.

You can find on how to provide traces here: https://github.com/vercel/next.js/issues/48748#issuecomment-1578374105 @feedthejim is working on adding a flag to also output CPU profiles which will allow narrowing down on potential causes further.

ivanhueso commented 11 months ago

I see some speed improvement in dev environment by replacing react-icons to @react-icons/all-files

So for instance I change Old: import { BiUser } from "react-icons"
New: import { BiUser } from "@react-icons/all-files/bi/BiUser

The only downside i see on this case is that @react-icons/all-files is not the most updated version. But is not that bad either.

mmahalwy commented 11 months ago

OOC, how/where are folks analyzing the trace files?

unclejustin commented 11 months ago

My trace here. Initial compile ~40 seconds. HMR ~3 seconds.

sannajammeh commented 11 months ago

@timneutkens this issue here has a very good repro. #51201 All seemed to start at 13.2.5-canary.26. That issue also relates to 2 others with the same conclusion.

arikarim commented 11 months ago

Solution: Version: 13.1 next.config:

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

kavinvalli commented 11 months ago

Here's my trace. I just saw after generating this that I could modularise the react-icons package. Will do that immediately. Would love if there's anything further I could do.

iJynx commented 11 months ago

trace + source

vercel / next.js