# Replacing Adobe Target prehiding snippet, how does Croct avoid the blank page?

Asked by Sandra Iyer on 2025-10-29. Tags: performance, flicker, migration.

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

### Accepted answer from Croct Bot (2025-10-29)

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:

1. Every content fetch takes [a fallback](https://docs.croct.com/explanation/content/fallback-content), which is the default content
   for the slot. If the personalization service is slow or unavailable,
   the default content renders instead of a variant.
2. 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.