What is causing so many repeated requests in development mode?
Unanswered
Tan posted this in #help-forum
TanOP
I've noticed that sometimes when I go to start up my app in development mode (
I'm using Next.js 16.2.11 and the app also connects to a Neon database. I don't see this behavior when I build the app and then start it. Anyone know what could be causing this or how I could try to understand what's happening better?
next dev --turbopack) and then I navigate to the homepage, the page refreshes a lot and I see so many duplicate requests in my console output, like this: GET /en 200 in 4.8s (next.js: 1985ms, proxy.ts: 5ms, application-code: 2.8s)
GET /en 200 in 459ms (next.js: 43ms, proxy.ts: 10ms, application-code: 406ms)
GET /en 200 in 365ms (next.js: 5ms, proxy.ts: 4ms, application-code: 356ms)
GET /en 200 in 389ms (next.js: 24ms, proxy.ts: 3ms, application-code: 361ms)
GET /en 200 in 372ms (next.js: 4ms, proxy.ts: 8ms, application-code: 360ms)
GET /en 200 in 419ms (next.js: 38ms, proxy.ts: 5ms, application-code: 376ms)
GET /en 200 in 356ms (next.js: 6ms, proxy.ts: 5ms, application-code: 346ms)
GET /en 200 in 395ms (next.js: 5ms, proxy.ts: 7ms, application-code: 383ms)
GET /en 200 in 370ms (next.js: 7ms, proxy.ts: 5ms, application-code: 358ms)
GET /en 200 in 383ms (next.js: 5ms, proxy.ts: 4ms, application-code: 374ms)
GET /en 200 in 394ms (next.js: 49ms, proxy.ts: 7ms, application-code: 337ms)
GET /en 200 in 371ms (next.js: 36ms, proxy.ts: 3ms, application-code: 333ms)
GET /en 200 in 335ms (next.js: 4ms, proxy.ts: 4ms, application-code: 327ms)
GET /en 200 in 358ms (next.js: 4ms, proxy.ts: 3ms, application-code: 351ms)
GET /en 200 in 354ms (next.js: 6ms, proxy.ts: 3ms, application-code: 345ms)
GET /en 200 in 418ms (next.js: 47ms, proxy.ts: 3ms, application-code: 368ms)
GET /en 200 in 357ms (next.js: 5ms, proxy.ts: 4ms, application-code: 348ms)
GET /en 200 in 366ms (next.js: 6ms, proxy.ts: 4ms, application-code: 356ms)
GET /en 200 in 388ms (next.js: 6ms, proxy.ts: 9ms, application-code: 373ms)I'm using Next.js 16.2.11 and the app also connects to a Neon database. I don't see this behavior when I build the app and then start it. Anyone know what could be causing this or how I could try to understand what's happening better?
12 Replies
I think it's because Dev mode uses strict mode and it causes more re-renders
A lot of the time I see double requests for page loading on prod but on Dev server I would see 4
TanOP
is there a way i can track down specifically what is causing each re-render? i just want to understand more of what is happening here
I'm not experienced enough to answer that question. I've just made peace with the multiple renders. It's react. It's hated for its unnecessary re-renders, just make sure you're using the react compiler and that'll help a little bit
TanOP
i didn't have any prior experience with React before starting my Next.js project. when you say to make sure you're using the react compiler, what does that mean?
In your next config set the react compiler option to true
Also, when you create a new nexjs application, go through the options of how to set up your project and select yes for react compiler
If you need, I can show you the exact syntax of what it would look like in the in the next config
TanOP
ahhh okay, just testing out enabling react compiler now, at first glance i am not seeing the re-renders so that is good! it also seems like it could potentially cause issues so i should make sure to test out different parts of my app. thank you!
TanOP
hm. yeah this is definitely causing weird behavior in my app 😅 i will keep trying different things
The react compiler is supposed to automatically optimize your code so you don't have to use memo and use callback as much
Highlander
use a ref guard for double invoke network calls .this stops the fetch or the network call form double calling because this keeps track of what has been called
[id, form] here you can use any param or slag .so the ref guard just remembering the network call and stops recalling it.
const fetchedIdRef = useRef<string | null>(null)
useEffect(() => {
if (!id || fetchedIdRef.current === id) return
fetchedIdRef.current = id // set before the async call, not after
fetchForEdit()
}, [id, form])[id, form] here you can use any param or slag .so the ref guard just remembering the network call and stops recalling it.