-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEXT-1143] Dev mode slow compilation #48748
Comments
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. |
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. |
entry next-app-loader
spans?)entry next-app-loader
spans?)
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. |
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. |
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 |
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: |
I confirm that next app dir on dev mode and dynamic routing are very very slow on docker now |
Changes in the past weekI'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:
You can try them using Help InvestigateIn 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 If possible follow these steps which would give me the best picture to investigate:
Known application-side slowdownsTo collect things I've seen before that cause slow compilation as this is often the root cause:
This and other slowdown reports are currently the top priority for our team. We'll continue optimizing Next.js with webpack where possible. |
entry next-app-loader
spans?)
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 🙏 |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
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 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 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! |
@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? |
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 |
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 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:
Thanks! |
Next canary due to lack of dependency support for React 19. My project must use React 18,how to solve it? o(╥﹏╥)o |
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. |
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? |
@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. |
@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 |
@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 👍 |
Hey @timneutkens thanks for the video, I'm trying to reproduce running:
But I keep geting this error: 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:
Update 2: I tried giving an absolute file path instead 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 |
You passed |
Are you using 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. |
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 One thing to note though that the flamegraph didn't feel anywhere near accurate (it was claiming that |
I've fixed it and rerun a few times with 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! |
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 |
Big thanks to that bro whose answer got folded! I wasted a whole day on this. Ended up fixing it by switching from Webpack to Turbopack with this VSCode setup. It finally works now! What a rough day... Hope this helps someone else! Oh, and I’m using the new App Router, by the way!
|
Hey @timneutkens, https:/helicone/helicone - we've been experiencing extremely slow dev compile times recently. Here's the trace: https://gist.github.com/kavinvalli/58946c70ed5d95265c13ac126356a8f1 Would be very helpful if you could take a look, since I'm not able to make out anything specific from |
Hey! Wondering if someone could look at my cpuprofile and trace? Link: https://gist.github.com/maxiedaniels/a949a901ce60bab38bee883e4c65c980 My pages take 5-10 seconds to load (from a refresh) in dev mode, but not in production. I've gone over all the normal causes and haven't found a solution. Thanks for the help!! |
Hi, Using next 14.2.13 in turborepo, not using turbopack. We're trying to utilize a generic page to handle CMS based routing, so we have: app/src/[locale]/[[...slug]]/page.tsx This has grown unsustainable as right now, even after attempts to trim down imports, we have around 4000 modules being logged during HMR, causing HMR to take ~2+ seconds. We've tried all sorts of attempts to dynamically import components/files, but most of our code is not "client" components, so using lazy or next/dynamic really doesn't have any real effect on our structure. We will probably resort to creating some hard coded level one navigation paths, but this is pretty strange behaviour and this issue was not this prominent in the pages router using a similar architechture. |
@timneutkens sorry for the wild ping. If you still have time to check other projects with slow compilation, here's the actual situation for us: For context
Questions
Thanks for your help and good luck with dealing with those types of issues (we know it's a pain) 🙏🏻 . |
Hey @timneutkens,
|
For us, --turbo is actually slower to compile initially than not using --turbo on [email protected]: Without --turbo
With --turbo
Unfortunately HMR is a whole different story though, and --turbo makes that part a whole lot faster. It would also help if the root route would be precompiled inline with For the time being, we've hacked the instrumentation hook to trigger a fetch, which helps, but it boggles my mind that this is not the default behavior of a framework that claims to be all about developer experience.
export function register() {
if (process.env.NODE_ENV === "development") {
console.log("PRELOADING ROOT ROUTE");
fetch(`http://localhost:${process.env.PORT}`);
}
} |
"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" Installing malware might help, but I'm sure we want to focus on solutions that don't pose security risks to our systems. |
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:
pages
andapp
and you're only working onapp
it will no longer compile the runtime forpages
. Note: this shifts the compilation of the runtime to when you first open a pageYou 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
NEXT_CPU_PROF=1
andNEXT_TURBOPACK_TRACING=1
(regardless of if you're using Turbopack, it only affects when you do use Turbopack) environment variable. E.g.:NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 npm run dev
NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 yarn dev
NEXT_TURBOPACK_TRACING=1 NEXT_CPU_PROF=1 pnpm dev
ctrl+c
).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..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.next.config.js
(if you have one) to https://gist.github.comKnown application-side slowdowns
To collect things I've seen before that cause slow compilation as this is often the root cause:
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 addmodularizeImports
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)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
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
https:/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:
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:
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: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: