Next.js Discord

Discord Forum

Unbelievably slow during development 60-120 second per page

Unanswered
Producdevity posted this in #help-forum
Open in Discord
ProducdevityOP
Our Next.js v15 project compiles extremely slowly in development, often 60 s to 2 min per page load—while production builds run quickly. Simple Prisma queries in development can also take ~12 s but are instant in production. This happens on multiple high‑spec machines (macOS and Windows), both with and without Docker.

Current setup
• next dev --turbopack with experimental options like optimizePackageImports and custom Turbopack rules.
• Prisma connects to a PostgreSQL database (tried both a remote Supabase instance and a local DB in Docker).
• The (docker) dev container runs prisma migrate deploy and seeds the DB on first run.
• Tailwind removed for testing; pages with and without images show the same slowness.

What we tried
1. Running the app outside Docker and inside Docker—no noticeable difference.

2. Disabling Turbopack

3. Try experimental flags like optimizeCss and optimizePackageImports

4. Using local vs. remote PostgreSQL and toggling Prisma debug logs. The same remote db that is snappy in production takes up to 12 seconds for simple queries in development.

5. Removing Tailwind by not importing globals.css in the layout.tsx. No measurable difference.

6. Using a DB with a handful of items instead of hundreds, no difference.

7. Tried running it on a PC with Windows 11 Ryzen 9 5900X, 64GB, RTX 4080s machine and a MacBook Pro i9 32GB Late 2018

8. Tried different Node versions, no difference


Development 60–120 s or longer for every page load. Production remains fast.

It’s not just the page loads, every interaction, every hover, every click, every scroll can take up to seconds. Our Playwright test (locally) consistently fail because a 1 minute timeout limit still wasn’t enough.

This is the website: https://www.emuready.com/

This is the public repo: https://github.com/Producdevity/EmuReady

⸻

Any suggestions on how to further diagnose or resolve these long compile/rebuild times would be greatly appreciated.

121 Replies

American black bear
Have you followed the steps on the documentation already? https://nextjs.org/docs/app/guides/local-development
ProducdevityOP
Yes, I did, I also have tried pretty much all the basic things you could think of. I even changed all export default to named exports because I read one comment in a github issue, that did of course nothing but it hopefully does illustrate how desperate i am getting😂
American black bear
@Producdevity Did you follow the tracing steps and investigated the trace? If you can send it over I can have a look as well
Japanese Spitz
@American black bear I've got this same issue, along with the dev server silently exiting very frequently, which overall makes for a pretty poor DX that I'm hoping I can solve. If I put together a trace file, would you mind if I also DM you about this?
Siamese Crocodile
skill issue lol
Japanese Spitz
@Siamese Crocodile that's not very helpful but thanks
@Japanese Spitz <@1398717873257713767> that's not very helpful but thanks
Siamese Crocodile
dont ask then lol
what u want from me an anser to the uniserse and everythin?
American black bear
@Japanese Spitz yeah fine to send over a trace file 👍
@American black bear <@366657064916746245> Did you follow the tracing steps and investigated the trace? If you can send it over I can have a look as well
ProducdevityOP
I am not sure if we are talking about the same thing but I have looked into this:
    "analyze": "ANALYZE=true next build",
    "analyze:turbo": "ANALYZE=true next build  --turbopack",
    "dev:profile": "NEXT_CPU_PROF=1 NEXT_TURBOPACK_TRACING=1 next dev --turbopack",


It generated .next/analyze which was 200mb+, which seemed excessive but I can't pretend to know if it is or not. Looking at the graphs they are stopped after 200ms. See I deemed it useless, but maybe I am missing something
I have this in next.config.ts, important detail i forgot to add haha
const withBundleAnalyzer = NextBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})
American black bear
@Producdevity I’m talking about .next/trace-turbopack. not bundle analysis 👍
What you have with dev:profile but without the next_cpu_prof
ProducdevityOP
Okay, give me one second. thanks!
I ran the dev server, went to 2 or 3 slow pages and ended up with a trace-turbopack file of 600MB+. is that normal?
American black bear
Yeah, that's correct
The trace keeps track of memory allocations / deallocations and time spent on every piece
ProducdevityOP
Alright, dank je wel. I am uploading it to my google drive and I'll share the link if that works for you
American black bear
Having a look!
@Producdevity just to double check: what version of Next.js are you on?
ProducdevityOP
15.4.2
production is on 15.3.x, i updated locally a day ago and performance hasn't changed
American black bear
Should be a bit better on 15.4.x but it depends on the application
ProducdevityOP
It could have improved, but since it takes sometimes up to 8 seconds or so per page load it haven't been able to enjoy the improvements
American black bear
/docs/api/swagger/page takes about 7,5 seconds or so to compile
ProducdevityOP
Yes, I am still waking up. I just passed out when I saw 17gb memory allocation
American black bear
The reason is /src/app/docs/api/swagger/SwaggerPage.tsx imports /node_modules/@scalar/api-reference-react/dist/index.js which results in a huge amount of compilation
I'm guessing this is a dependency of your application and not something you're building yourself right?
Ah yes: https://scalar.com/
ProducdevityOP
yes, it's a dependency
Maybe that one is a bad example. I am created a new trace with pages that are actually visited by users
It's a lot less extreme, I have made a lot of changes but they all felt like minor optimizations. I currenlty still see pages that take between 3 to 4 seconds
I am not sure what is considered "normal", but 7-8GB seems like a lot.
American black bear
You're looking at allocated -> deallocated -> persisted
It's only 1.5GB persistently used
Parsing code takes a lot of allocations
ProducdevityOP
Would this be considered "normal"?
American black bear
(persistently used is what's cached to not redo work)
import {
  PerformanceBadge,
  Pagination,
  SuccessRateBar,
  LoadingSpinner,
  SortableHeader,
  Button,
  ColumnVisibilityControl,
  Tooltip,
  TooltipTrigger,
  TooltipContent,
  DisplayToggleButton,
  VerifiedDeveloperBadge,
  EditButton,
  ViewButton,
  Badge,
  ListingVerificationBadge,
} from '@/components/ui'

this part is a pretty recent change. like I mentioned earlier I changed everything from default exports to named exports + combined exports in index.ts. the problem existed before this change, this was actually a hopeless attempt to improve the performance. Which makes no sense, but I've seen a single github comment suggesting this and I was already pretty desperate so I tried it anyway
American black bear
Yeah changing imports/exports doesn't make a difference with Turbopack (it does with webpack) as we analyze re-export patterns
ProducdevityOP
So that was a waste of time😂
American black bear
This type of file causes extra memory usage with webpack. No difference with Turbopack though: https://github.com/Producdevity/EmuReady/blob/staging/src/components/ui/index.ts
Do you reboot the dev server very often?
Every time you reboot currently it loses the cache because it's only in-memory.
We're working on disk caching but there's a few bugs we still want to iron out
@American black bear Do you reboot the dev server very often?
ProducdevityOP
Not necessarily, maybe once every 30-40 if I had to guess
I often get a warning that I am using a slow disk when starting up the dev server. I am not sure if this tells you anything at all
American black bear
Are you on Windows or Mac?
ProducdevityOP
I don't remember the exact warning, but it suggests to check if I am using a remote or cloud directory. Everything runs locally on a modern macbook with an ssd. Spotlight and alfred also don't index the folders
Mac, but I have tested it on windows too. I included the specs in the original post
American black bear
Do you happen to have antivirus?
And the project doesn't run in docker right?
ProducdevityOP
Tried running it on a PC with Windows 11 Ryzen 9 5900X, 64GB, RTX 4080s machine and a MacBook Pro i9 32GB Late 2018

And currently I am on a Macbook Air M4 16GB
@American black bear Do you happen to have antivirus?
ProducdevityOP
No, and on windows I also tried excluding it from windows defender
@American black bear And the project doesn't run in docker right?
ProducdevityOP
No, I tried docker but the performance is worse. I think I've read something about that on the nextjs docs, so I stopped using it
American black bear
Yeah Docker is worse usually
ProducdevityOP
I could be wrong, I don't remember the exact reason. but it did slow things down even more
Alright
What surpises me the most is that even the prisma calls are extremely slow in development. It doesn't matter if it's a local db or a remote Subabase db that's relatively close to me.
While being fast in production.
American black bear
Overall your trace doesn't have anything off from what I can see, no super long compilation (i.e. what we see with misconfiguration of Tailwind or such). But you're saying you're rebooting every 30-40 minutes?
ProducdevityOP
How does that affect this specifically?
@Producdevity I haven't been paying close attention to it, but if I had to guess, something like that
American black bear
Is there a specific reason for rebooting? Or just switching projects?
@American black bear This sounds off but not specific to the Turbopack compilation time at least
ProducdevityOP
But just for my own sanity, a 4second page load (even static pages) isn't "normal" during development?
American black bear
When you boot the server -> go there the first time
After that no, not normal
The first time you navigate to /listings/page we have to compile your code
@American black bear Is there a specific reason for rebooting? Or just switching projects?
ProducdevityOP
My laptop gets extremely slow running the dev server, I am currenlty working on a kotlin android app, when I need to rebuild that I do sometimes stop the dev server
American black bear
If you navigate to /listings/page the first time 3.36s is spent in compilation. Then after that the code can run, and that's executing the application code (not something we can affect specifically)
If you then refresh the page it doesn't compile that route again, only runs the application code to render the page
Only when you change the code and it'll recompile the smallest piece of work
ProducdevityOP
it is a lot faster the second time, but I mostly feel like I kinda solved this issue by throwing more raw power at the problem. My i9 32gb macbook simple can't run the dev server and have an IDE open at the same time. I know it's not the newest laptop, but it's not something i experience with any other project i am working on
When working on other next projects, for my day job for example, this isn't an issue at all.
American black bear
My suspicion is that something else in your project is causing problems if the queries are also taking forever
ProducdevityOP
Thank you for your time, are there things you could recommend me to look into or try?
I don't think there's much you can do if the traces don't show any signs of this being related to turbopack
American black bear
Is it possible to run your application? Since it's open source
ProducdevityOP
I would really appreciate that, if that has a chance of giving you more insight
I am currently working on the staging branch
this is the only relevant part of the readme. the RAWR , CLERK and TGDB values in .env aren't required for most pages
i think
ProducdevityOP
hacks like this don't affect turbo the same way it improves webpack, or does is have no effect at all on performance for the dev server?

This prevented webpack from parsing the whole library and avoids duplicate module instantiations every time it got imported, but based on what you just said, this seems pointless when using turbo. Or did I misunderstand that?
American black bear
That type of re-exporting is not ideal, not needed indeed
American black bear
Btw on the topic of memory you can try next@canary we've upgraded mimalloc which solved a leak in the allocator itself
ProducdevityOP
Sure, I will try it out! is it close to being stable?
American black bear
We're going to backport the mimalloc change to stable. The rest goes to Next.js 16 (per the last blogpost we did) but that's okay, really only need that upgrade for this case
ProducdevityOP
That sounds great, I will try it out
American black bear
@Producdevity is there a specific way to run the sqlite db?
npx prisma db push fails on "Can't reach database server at localhost:5432"
DATABASE_URL and DATABASE_DIRECT_URL are both "file:./dev.db"
ProducdevityOP
I was using that early on, I honeslty haven't tested it lately. but before I waste your time. I just switched to a local db and seeding it took 3 seconds instead of 17 minutes using supabase. last time I tried this there have been some changes, I am currenlty tracing back what it could have been
So the slow prisma calls seem to be unrelated.
Well now they are, last time I tried it it was just at slow. And docker still takes forever to seed the local db running inside the container. but as you mentioned, that's currently just expected
I am not sure why. I am from the netherlands and the supabase db is around the corner.
American black bear
So there's high variance in seeding it?
(I'm also in NL btw 😄)
ProducdevityOP
the first page load takes a while, but after that it's very fast. I like to think that the issue was the database after all, it doesn' t explain why it performed so bad on 3 different computers before. even when running the db locally.

I will probably waste a week trying to figure this out. I am glad it's resolved, but it bothers me even more that I don't know why 😂
@American black bear (I'm also in NL btw 😄)
ProducdevityOP
I know hahaha, I follow your work sir 🤓
American black bear
Yeah that sounds crazy
ProducdevityOP
I don't know what to say, all I can say is I swear I'm not crazy and I tried this before multiple times 😂
American black bear
But we've seen slow Prisma before, just never dug into it (not specific to Next.js)
@American black bear But we've seen slow Prisma before, just never dug into it (not specific to Next.js)
ProducdevityOP
I for sure will, stuff like this will keep me up at night. If I happen to find anything I will create a Github issue documenting it. locally I am using prisma-client instead of prisma-client-js but I have a hard time believing that the impact is that massive. It's the only change I can think of that happened in the last few days
well, a few hours ago actually. I haven't even pushed this code.
American black bear
Yeah I doubt it's that, maybe underlying queries were slow or the db engine was... weird
ProducdevityOP
It's the exact same db and version, I just checked. Anyway, thank you so much for your time. I really appreciate it. I wish I could resolve this issue with a solution for others but I am happy it works now. I will dive in and see if I can find the cause and share this
American black bear
You can add:
experimental: {
  turbopackPersistentCaching: true,
}

On canary to see what persistent caching will look like soon
ProducdevityOP
I will try that out, thanks!
American black bear
Wouldn't recommend using it day-to-day right now as you might run into bugs
But it shows what the future looks like
ProducdevityOP
I don't think my 7 users mind, but won't use it in other projects haha
American black bear
It's really for yourself while developing, you could hit cases where changes don't apply and such
ProducdevityOP
As long as I keep that in mind it's probably fine, I haven't moved prod builds over to turbo anyway
American black bear
(There's some edge cases
When you do hit that case or other errors that look out of place you can let me know, and also to unblock yourself delete .next (though eventually you shouldn't need to delete it)