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

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

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

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

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

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.

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.

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

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.

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)

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.

its slowing down the development..!

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.

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.

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.

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.

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

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

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 :(

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

Linked a bunch of related issues on this:
#50332

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

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.

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 Thanks for taking a look! I think you're right; I think the slowness comes from the Vanilla Extract plugin, probably in combination with Mantine that we're using. I've seen quite a few issues regarding this in their repository. I tried adding optimizePackageImports: ['@mantine/core', '@mantine/dropzone', '@mantine/tiptap'], but it didn't seem to help a lot. But at this point, it seems more like a webpack issue to debug rather than a NextJS one, so I suppose I'll be taking a look into that next.

Thanks for taking the time to look into this. I really appreciate it! By the way, is there an instruction somewhere on how to load those traces into Jaeger and debug by ourselves?

@dstoyanoff I'll have a look at the trace soon, you should be able to try Turbopack with this configuration based on that being the only webpack configuration: https://x.com/timneutkens/status/1805180098703675882

Hello @timneutkens, were you able to look into this?

@timneutkens thanks really for good inside, we did actually able to drop our compile/load time from 100-200s to around 1-2s. Main issues we missed:

• content directory for tailwind.config.js which we just ignored node_modules check for one package (which we did it for 4 packages but 1 of them was missing it)
• Barrel files within monorepo packages which were preventing tree-shaking, then added it to optimizePackageImports

Also we upgrade from v14.1.4 to v14.2.5.

So far cold start takes around 10-20s but later gets much much faster.

@timneutkens Can we get a bit more systematic here and maybe also collect more general instructions? I know the detailed debugs are helpful for individual users and also for next to understand what is going on, but it will not allow for a good dx out of the box. Many recommendations you need to find by browsing through very large GitHub issues and lots of it is outdated.

In addition to that, there still seem to be a more fundamental issues, because I keep reading here about initial compile times of 10s and even reloads that exceed seconds after a very fair share of optimization. I can only compare that to other frameworks I worked with and given the very high hardware demands (e.g. 64GB RAM and M1 Max are not sufficient to be really fast), this is frustrating.

So what I gathered so far:

Maybe there is a chance you add something to the next documentation about this?

And then back to my problem:

• We tried all optimizations we could find
• We tried the optimizations you suggested
• We cannot use turopack because of a bug with server relative imports
• We are still having a very bad dx. Is there anything we can do to move forward from here?

@timneutkens Here's our performance gist:

https://gist.github.com/chriscaruth/8e427460580cf44db32a17fad85f31bd (updated)

We are using next@14.2.4 due to next@canary requiring react@19.

• My machine is M3 MBP/36GB Ram.
• Seeing route compile times from ~3s - 8s

@PILLOWPET thanks for sharing the trace, we'll take a look! Note that it's currently expected that if you have a certain amount of code the memory usage is higher than webpack, this is something we're working on optimizing further. See https://nextjs.org/blog/next-14-2#turbopack-for-development-release-candidate

Hi @timneutkens, have you had the time to take a look at our trace ?

@timneutkens Thanks for taking a look! I think you're right; I think the slowness comes from the Vanilla Extract plugin, probably in combination with Mantine that we're using. I've seen quite a few issues regarding this in their repository. I tried adding optimizePackageImports: ['@mantine/core', '@mantine/dropzone', '@mantine/tiptap'], but it didn't seem to help a lot. But at this point, it seems more like a webpack issue to debug rather than a NextJS one, so I suppose I'll be taking a look into that next.

Thanks for taking the time to look into this. I really appreciate it! By the way, is there an instruction somewhere on how to load those traces into Jaeger and debug by ourselves?

I'm having trouble with Mantine as well. Compilation takes 60-70 seconds for a single page. Were you able to discover something?

@DenisBessa Unfortunately, nothing ground-breaking, no. I did see a lot of issues regarding performance on both vanilla-extract and Mantine repositories, but none of the proposed solutions changed anything for us. I wanted to try to profile our webpack build via the ProfilingPlugin, but every time I did, the result was corrupted, so I wasn't able to find the root problem. I also tried out BundleAnalyzer but that also didn't give me a lot of helpful info.

I think, in this case, it would be more worthwhile debugging the webpack build itself rather than NextJS configuration because I think that's where the problem lies. If I discover anything, I'll let you know.

@DenisBessa Unfortunately, nothing ground-breaking, no. I did see a lot of issues regarding performance on both vanilla-extract and Mantine repositories, but none of the proposed solutions changed anything for us. I wanted to try to profile our webpack build via the ProfilingPlugin, but every time I did, the result was corrupted, so I wasn't able to find the root problem. I also tried out BundleAnalyzer but that also didn't give me a lot of helpful info.

I think, in this case, it would be more worthwhile debugging the webpack build itself rather than NextJS configuration because I think that's where the problem lies. If I discover anything, I'll let you know.

I've spend a few hours on this, and was able to reduce the compilation time, in my case, from 60 - 70 seconds to 18 seconds (without using TurboPack).

1. Added mantine-react-table to optimizePackageImports;
2. Added the following packages to serverExternalPackages: 'pdfjs-dist', 'xlsx', '@azure', '@opentelemetry', '@sentry', 'node-forge', 'pdf-lib', 'jose'.

I'm not sure abou the impacts from these changes in production, so for now they are enabled only in my dev environment.

I hope this can be useful.

@timneutkens If this is still a standing offer, would greatly appreciate a look if possible
gist

Hello 👋 @timneutkens ,

Here is the requested gist
📎 next.config , tailwind.config , trace

My development server is extremely slow taking 20 sec for content related change

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

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

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

@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

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

1. @svgr/webpack
2. 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 ?

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.

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!

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!

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

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

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

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