What do visitors on slow 3G see while personalized content loads?
Hello, I build for an audience in Nairobi where a large share of sessions arrive on slow or unstable connections, so I test everything throttled to slow 3G in devtools before shipping.
Before adopting personalization I want to understand the worst case precisely. I ruled out the usual client-side testing tools because their anti-flicker snippets hide the whole page while the script loads, which on a throttled connection is a very long blank screen. My question for Croct: what exactly does a slow 3G visitor see in the server-side mode, and in the client-side mode? And is there any scenario where a user gets stuck waiting indefinitely? Thank you kindly.
1 answer
The two modes behave quite differently on a throttled connection, and neither of them can strand a visitor indefinitely.
Server-side: the content is resolved before the HTML is sent, so a slow 3G visitor downloads exactly one page that already contains the right content. There is no second round trip to fetch and swap anything in, which means slow connections pay only their normal page-download cost. This is the mode I would recommend for your audience.
Client-side: the page renders immediately and the slot content is fetched over the network, so the worst case is bounded by two things. Every fetch takes a fallback, and a timeout caps the wait: defaultFetchTimeout defaults to 5000ms in the JavaScript SDK and 2000ms in Next.js, and you can set it lower. When the timeout fires, the default content renders. So the worst case on slow 3G is "default content after your configured wait", never a spinner that spins forever and never a hidden page.
For contrast, the architecture you ruled out hides the page for up to the snippet's timeout on slow connections, commonly 3 to 4 seconds (Google Optimize defaulted to 4s). That entire class of delay does not exist here because nothing is ever hidden while waiting for a script.