First request made after starting up the dev server takes too much time
Answered
Asiatic Lion posted this in #help-forum
Asiatic LionOP
Hello,
I have an issue in a next js project where the first request to the dev server takes a lot of time to complete (around 1 minute). I ran the profiler and noticed that most of that time is because FSWatcher.close is running. The rest of the requests take between 5 and 10 secs to complete, and I don't see these calls to FSWatcher.close anymore. Is this normal?
Bear in mind that I'm working on a monorepo and each page compiles around 4k modules.
I attached a couple of screenshots from the profiler for first and second page load.
Thanks in advance!
I have an issue in a next js project where the first request to the dev server takes a lot of time to complete (around 1 minute). I ran the profiler and noticed that most of that time is because FSWatcher.close is running. The rest of the requests take between 5 and 10 secs to complete, and I don't see these calls to FSWatcher.close anymore. Is this normal?
Bear in mind that I'm working on a monorepo and each page compiles around 4k modules.
I attached a couple of screenshots from the profiler for first and second page load.
Thanks in advance!
Answered by Luke
Given you're working in large a monorepo, I'd say that this is just an unfortunate side effect.
For reference, I have a relatively small app that takes like 3 - 10 seconds on initial loads, so I can only imagine a monorepo with 4k~ modules would be much longer.
It could be worth exploring using the experimental [turboPack](https://nextjs.org/docs/architecture/turbopack) option, or just using [turborepo](https://turbo.build/) as a whole.
For reference, I have a relatively small app that takes like 3 - 10 seconds on initial loads, so I can only imagine a monorepo with 4k~ modules would be much longer.
It could be worth exploring using the experimental [turboPack](https://nextjs.org/docs/architecture/turbopack) option, or just using [turborepo](https://turbo.build/) as a whole.
5 Replies
Given you're working in large a monorepo, I'd say that this is just an unfortunate side effect.
For reference, I have a relatively small app that takes like 3 - 10 seconds on initial loads, so I can only imagine a monorepo with 4k~ modules would be much longer.
It could be worth exploring using the experimental [turboPack](https://nextjs.org/docs/architecture/turbopack) option, or just using [turborepo](https://turbo.build/) as a whole.
For reference, I have a relatively small app that takes like 3 - 10 seconds on initial loads, so I can only imagine a monorepo with 4k~ modules would be much longer.
It could be worth exploring using the experimental [turboPack](https://nextjs.org/docs/architecture/turbopack) option, or just using [turborepo](https://turbo.build/) as a whole.
Answer
Just curious any particular reason to use turbo over nx, since nx is faster? https://nx.dev/concepts/turbo-and-nx
Turbo is already buggy and strenuous enough to set up (especially the next flag) on an existing repo
I wouldn’t point someone the way of nx until they have turbo itself figured out imo
Gotcha, because of the ease of setup