All questions

Request timeout errors only in the Next.js app, JS SDK on the same network is fine

Asked by Ken Watanabe on

KWKen Watanabe

I build for users in Nairobi where connectivity can be slow and variable, so I watch latency behavior closely. We run two properties: one on the plain JavaScript SDK and one on @croct/plug-next. The Next.js one intermittently logs "Request timeout" errors during traffic from mobile networks, while the JS SDK property never times out under the same conditions.

Before I start tuning blindly: do the two SDKs actually behave differently around timeouts, or should I be looking for a problem in our infrastructure? I would appreciate a precise answer if anyone knows the defaults.

Was this helpful?

2 answers

ABAisha BelloAccepted answer

They do behave differently, and the difference explains exactly what you are seeing. The default fetch timeout is 5000ms in the JS SDK but only 2000ms in the Next.js SDK. The Next.js default is tighter because a server-side fetch blocks the whole page render, so it fails fast by design. The same network latency that sails through on the JS property can trip the 2 second limit on the Next one.

Two things to do:

  1. Raise the limit where it makes sense for your audience via the defaultFetchTimeout option.
  2. More importantly, always pass a fallback to your content calls. With a fallback, a timeout degrades gracefully to default content instead of surfacing as an error. For a low-bandwidth audience this is the setting that actually protects the user experience.

With both in place the timeout stops being an error and becomes a controlled worst case.

Was this helpful?
KWKen Watanabe

Precise indeed, thank you. Raised the timeout to 4000ms and added fallbacks everywhere; the error rate dropped to zero overnight.

Jjorge_mtz

Small caution from someone who tuned this before: do not just crank defaultFetchTimeout way up on the server side. Every millisecond you allow is a millisecond your slowest visitors might wait for first byte. The fallback is the real fix, the timeout number is just where you draw the line between personalized and default content. We settled on 3000ms after looking at our own latency distribution rather than picking a round number.

Was this helpful?
Still have questions?