App router slow performance when using dynamic route

[manuelseisl]

Verify canary release

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

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:43 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8112
    Binaries:
      Node: 18.16.0
      npm: 9.6.6
    Relevant packages:
      next: 13.4.3
      eslint-config-next: 13.4.3
      react: 18.2.0
      react-dom: 18.2.0

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

Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue or a replay of the bug

https://github.com/manuelseisl/nextjs-demo

To Reproduce

Open link:
https://nextjs-demo-six-kohl.vercel.app

Go to "console -> network"
Document loading time is about 30 - 40 ms

when opening link with dynamic route:
https://nextjs-demo-six-kohl.vercel.app/de/asdf
Document loading time is about 170 - 180 ms

Describe the Bug

Loading performance is about 4 times slower when using dynamic routes. We also tried with page router and the result was the expected behavior

Expected Behavior

Better loading performance for document when using dynamic routes with app router

Which browser are you using? (if relevant)

Chrome 113.0.5672.127

How are you deploying your application? (if relevant)

Vercel

[oalexdoda]

Similar issue here.

The app router is incredibly slow for me during dev as well. Also it looks like it prefetches routes that it shouldn't, including hundreds of dynamic paths - flooding the server memory pretty much. 7000 modules that used to be compiled in 6 seconds using the /pages directory now take somewhere like 60-90 seconds. And that's per route.

Not sure if it's related to appDir (which I assume it is) or that it doesn't config.modularizeImports properly?

[joacub]

Similar issue here.

The app router is incredibly slow for me during dev as well. Also it looks like it prefetches routes that it shouldn't, including hundreds of dynamic paths - flooding the server memory pretty much. 7000 modules that used to be compiled in 6 seconds using the /pages directory now take somewhere like 60-90 seconds. And that's per route.

Not sure if it's related to appDir (which I assume it is) or that it doesn't config.modularizeImports properly?

Same 7000 modules takes 40 seconds

[poorscousertommy8]

I can replicate that too. The root path is fine, dynamic paths are actually quite a bit slower. This phenomenon did not occur in pages router.

[oalexdoda]

Sometimes it takes even 2-3 minutes for the initial build. And when navigating between routes or when editing a file, it's like it re-compiles all modules. Maybe there's a bug between the App directory, transpiled modules, and modularized imports? It's acting as if no modules are getting modularized (i.e. @mui) and as if it needs to reload all of them for some reason.

[oalexdoda]

Running this on an 8-Core Intel Core i9 64 GB RAM so it's not a hardware resource issue. In pages dir it's around 6 seconds. But in appDir, RIP.

[iukea1]

Have any of you guys tried this with turbo pack?

(I have not used it nor known its limitations)

[joacub]

Have any of you guys tried this with turbo pack?

(I have not used it nor known its limitations)

Turbopack is even worse getting 50 seconds to build simple pages. Hot reloading is fast super fast but cold or lazy build is a disaster

[iukea1]

Have any of you guys tried this with turbo pack?

(I have not used it nor known its limitations)

Turbopack is even worse getting 50 seconds to build simple pages. Hot reloading is fast super fast but cold or lazy build is a disaster

Yaaaa damnnnn

I saw another thread about 1 hour ago where people were talking about how slow turbopack is.

[jilv220]

Similar issue here.

The app router is incredibly slow for me during dev as well. Also it looks like it prefetches routes that it shouldn't, including hundreds of dynamic paths - flooding the server memory pretty much. 7000 modules that used to be compiled in 6 seconds using the /pages directory now take somewhere like 60-90 seconds. And that's per route.

Not sure if it's related to appDir (which I assume it is) or that it doesn't config.modularizeImports properly?

Yep, it prefetches too much for some reason.

[oalexdoda]

Turbopack won't work me at all. It can't resolve paths and it won't even start up. But why would the app router have a 20X worse performance?

[duongductrong]

The same, hope this topic can resolve soon :((. It still take more than 200% cpu of my laptop for compile, i am using mac m1 but it very hot when I use next 13

[oalexdoda]

Even on an M2 Max with 96GB RAM it still takes an insane amount of time to compile. Someone here suggested a downgrade to an older Next version, but there's gotta be a tweak coming, right? I mean this is a pretty critical bug in Next.

[joacub]

Even on an M2 Max with 96GB RAM it still takes an insane amount of time to compile. Someone here suggested a downgrade to an older Next version, but there's gotta be a tweak coming, right? I mean this is a pretty critical bug in Next.

Seems like they are working on it, there is one pending update of turbopack and swc that seems promising get faster compiling times. So let’s see in a couple hours when they release the next canary version.

[joacub]

Check this ———> #50519

[poorscousertommy8]

originally it was about the performance in production mode. the catch-all routes are slower in response than in the pre App Router version. Hopefully this will be fixed soon.

[oalexdoda]

Check this ———> #50519

Downgraded to 13.2.3 and compile times are a LOT better. I'm not using Turbopack because of the complexity of our project and all the unsupported features, but I think webpack projects should get a fix too. Also referenced a bunch of other related issues because this seems to be related to something other than just dynamic routes. It's pretty much every route.

[alexdanilowicz]

+1 to all of this. _app router slowness is unacceptable, will be downgrading for now.

- event compiled client and server successfully in 8.7s (4597 modules)

[joacub]

Check this ———> #50519

No change, I think now is even worse…. This is stating to be really annoying, and now I’m starting to think that no body cares at nextjs team…, this needs to be resolved very soon this can no go longer, this way is impossible to work with 40~ second compiling times, does not matter if Turbopack or webpack, webpack is even faster ….. I will appreciate any response from next team to know what is the status of this and or if has solution which I think, of course have. I may go back (if this stay this way longer) to my own implementation (no nextjs) which was way way faster without compiling enter you the whole project in 30 seconds and then no wait per lazy builds and super fast hmr.

[oalexdoda]

Check this ———> #50519

No change, I think now is even worse…. This is stating to be really annoying, and now I’m starting to think that no body cares at nextjs team…, this needs to be resolved very soon this can no go longer, this way is impossible to work with 40~ second compiling times, does not matter if Turbopack or webpack, webpack is even faster ….. I will appreciate any response from next team to know what is the status of this and or if has solution which I think, of course have. I may go back (if this stay this way longer) to my own implementation (no nextjs) which was way way faster without compiling enter you the whole project in 30 seconds and then no wait per lazy builds and super fast hmr.

Are you using @mui/icons-material or another large icons library? I started changing all tree shaked imports (like import { DeleteOutlineOutlined } from '@mui/icons-material'; to import DeleteOutlineOutlined from '@mui/icons-material/DeleteOutlineOutlined'; - even though the library is using the modularizeImports option in the Next config, and I see SOME degree of improvement, but still slow. I had to get a more powerful hardware to reduce the compile times. But obviously some random memory leak or whatever shouldn't be a reason to force the need for expensive hardware.

[joacub]

Check this ———> #50519

No change, I think now is even worse…. This is stating to be really annoying, and now I’m starting to think that no body cares at nextjs team…, this needs to be resolved very soon this can no go longer, this way is impossible to work with 40~ second compiling times, does not matter if Turbopack or webpack, webpack is even faster ….. I will appreciate any response from next team to know what is the status of this and or if has solution which I think, of course have. I may go back (if this stay this way longer) to my own implementation (no nextjs) which was way way faster without compiling enter you the whole project in 30 seconds and then no wait per lazy builds and super fast hmr.

Are you using @mui/icons-material or another large icons library? I started changing all tree shaked imports (like import { DeleteOutlineOutlined } from '@mui/icons-material'; to import DeleteOutlineOutlined from '@mui/icons-material/DeleteOutlineOutlined'; - even though the library is using the modularizeImports option in the Next config, and I see SOME degree of improvement, but still slow. I had to get a more powerful hardware to reduce the compile times. But obviously some random memory leak or whatever shouldn't be a reason to force the need for expensive hardware.

I’m doing the same, and it’s slow as a hell, ranging from 10-50 seconds build

[JunkyDeLuxe]

There is a hudge bug or something is not correct in the implentation of the App router. I use the last canary version v13.4.5 and i can confirm, with next dev (under docker), the app router is very very slow, I have to wait sometimes some seconds, almost ten (WTF), in order to display a simple web page with dynamic fetch GET method, with some client components in it ... Everything is compiling a lot of time, a lot of modules are compiling, 3000+, 4000+, dunno what is going here
Why there is no response from the NextJS core team about that ...

[joshua-lawrence]

Also having a same issue, starting to regret using Next.js for development because of the horrible performance in the dev environment.

[joacub]

There are several commits these days about performance, and seems working worse, … going in the wrong direction

[timneutkens]

I've posted a reply there. Let's consolidate these issues into one as they're all about the same thing.
#48748 (comment)

There are several commits these days about performance, and seems working worse, … going in the wrong direction

I understand that you're frustrated. In order for me to help please provide the .next/trace as outlined here: #48748 (comment). It will allow me to provide you with insights into why your application is compiling unexpectedly slow. Thanks Johan 🙏

[joacub]

I've posted a reply there. Let's consolidate these issues into one as they're all about the same thing. #48748 (comment)

There are several commits these days about performance, and seems working worse, … going in the wrong direction

I understand that you're frustrated. In order for me to help please provide the .next/trace as outlined here: #48748 (comment). It will allow me to provide you with insights into why your application is compiling unexpectedly slow. Thanks Johan 🙏

I will when have a chance send you a trace, and for turbopack I don’t know how to send you that as turbo pack does not yield any trace.

But you can simulate this very easily using material ui with next-intl and you will see this only putting one component. I have optimized already the import as much as I can and still really slow, 30 seconds per page.

thanks for responding.

[l-you]

The App directory was a great idea, but the realization is very disappointing. We encountered more than 16 bugs that made our development and production much worse than before.

[timneutkens]

@GM33 please follow the other issue I linked and provide the trace + cpuprofile: #48748 (comment)

Besides that we shipped 13.4.8 yesterday that holds many development performance optimizations: https://twitter.com/nextjs/status/1675929873720680459

We encountered more than 16 bugs that made our development and production much worse than before.

@rusted-love Sorry to hear that you're struggling, we're working hard on fixing bugs and optimizing performance.
I had a look at the bug reports and it seems you've opened 2 issues (both closed) and commented on 7 issues (including your own). Can you report the other issues you've run into so that we can triage them? Thank you!

[timneutkens]

Going to lock this issue as #48748 is where we're tracking performance work.