Replacing Adobe Target prehiding snippet, how does Croct avoid the blank page?
My team has run Adobe Target for several years and we are evaluating alternatives. Our lived experience with at.js prehiding has not been good: the snippet hides the page for up to the 1500ms timeout, and when Target responds late, users occasionally see a blank page before content appears. We tuned the timeout repeatedly and never found a value that was safe on slow connections without being visible on fast ones.
My question for Croct is about the failure mode. If there is no prehiding mechanism, what exactly happens when the personalization service is slow or entirely unavailable? I need to understand the worst case before proposing a migration.
1 answer
No prehiding is involved in Croct's architecture. Content is resolved server-side before the HTML is sent to the browser, so there is no window in which the page must be hidden while a script decides what to show. The tradeoff you spent years tuning simply does not exist in this model.
The failure mode you are asking about is a fault-tolerant fallback:
- Every content fetch takes a fallback, which is the default content for the slot. If the personalization service is slow or unavailable, the default content renders instead of a variant.
- Fetches are bounded by a timeout: 2000ms by default in the Next.js SDK and 5000ms in the JavaScript SDK, both configurable. After the timeout, the fallback renders. There is no state in which the user waits indefinitely or sees a blank page.
One more point worth noting for your evaluation: paused experiences also serve the default slot content. This means the fallback path is exercised routinely in normal operation, not only during outages, so a degraded state is a well-worn code path rather than an emergency branch.