Delay in domain-task Promise Resolution when Server Side Rendering #30

New Issue

fergalmoran · 2025-08-09T17:14:44Z

fergalmoran commented

2025-08-09 17:14:44 +00:00

Originally created by @timothywisdom on 7/6/2018

Our React app is showing a consistent 4 secs to do server side rendering (SSR) on about 70% of initial requests for the app. SSR in our app waits for two promises to resolve before it performs the final render of the app. The promises are React-Loadable (to fetch all the code-split async components) and domain-task (to fetch all the async API data to populate those components).

We call renderToString 3 times in this process (in boot-server.tsx):

initial render to wake up and fetch loadable components
domain-task render to fetch all async API data to populate components
final render to get the full page with all components and data.

I've traced the 4 sec delay to the domain-task promise (for reference, it's the params.domainTasks.then() call in boot-server.tsx of the default app). I have also measured the time for each API data call on the server and they are negligible: 10ms-100ms. There are not enough API calls in a single domain-task promise to account for 4 seconds.

I have read that renderToString is blocking and that the Node process does nothing else until this is complete. I have also verified that there is exactly one Node process on each .Netcore web server (or at least the PID of the Node Process doing the SSR is the same per web server).

I cannot figure out what is causing the 4 second delay. It feels like something is blocked and some 4sec timer kicks in to move things forward. Has anyone experienced this with SSR? Does anyone have any leads on how I can investigate this further? Is it possible to have .Netcore spin up more Node processes, instead of just using one?

*Originally created by @timothywisdom on 7/6/2018* Our React app is showing a consistent 4 secs to do server side rendering (SSR) on about 70% of initial requests for the app. SSR in our app waits for two promises to resolve before it performs the final render of the app. The promises are React-Loadable (to fetch all the code-split async components) and domain-task (to fetch all the async API data to populate those components). We call renderToString 3 times in this process (in boot-server.tsx): 1) initial render to wake up and fetch loadable components 2) domain-task render to fetch all async API data to populate components 3) final render to get the full page with all components and data. I've traced the 4 sec delay to the domain-task promise (for reference, it's the `params.domainTasks.then()` call in boot-server.tsx of the default app). I have also measured the time for each API data call on the server and they are negligible: 10ms-100ms. There are not enough API calls in a single domain-task promise to account for 4 seconds. I have read that [renderToString is blocking](https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8) and that the Node process does nothing else until this is complete. I have also verified that there is exactly one Node process on each .Netcore web server (or at least the PID of the Node Process doing the SSR is the same per web server). I cannot figure out what is causing the 4 second delay. It feels like something is blocked and some 4sec timer kicks in to move things forward. Has anyone experienced this with SSR? Does anyone have any leads on how I can investigate this further? Is it possible to have .Netcore spin up more Node processes, instead of just using one?

fergalmoran closed this issue

2025-08-09 17:14:44 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#30