Attributes
data-next-skeleton
| Type | Marker attribute (no value) |
| Required | yes |
| Default | — |
Marks an element as a skeleton placeholder. The SDK ships with a built-in CSS rule that fades these elements out after next-display-ready is added to <html>:
[data-next-skeleton] {
transition: opacity 0.3s ease-out;
}
.next-display-ready [data-next-skeleton] {
opacity: 0;
pointer-events: none;
}Override the rule in your own stylesheet to use a different transition (e.g., display: none or a visibility: hidden).
data-next-await (deprecated)
| Type | Marker attribute |
| Status | Deprecated |
A legacy alias for data-next-skeleton. The X-ray debugger still recognizes it, but the built-in stylesheet does not target it. New code should use data-next-skeleton instead.
If you have existing markup using data-next-await, replace it:
<!-- old -->
<div data-next-await>...</div>
<!-- new -->
<div data-next-skeleton>...</div>How the SDK Decides "Ready"
The next-display-ready class is added to <html> after the first complete DOM scan by AttributeScanner. That happens after:
- The SDK loads and the campaign API responds (or fails — the class is still added so skeletons clear)
- All initial display enhancers have populated their bound elements
cartStorerehydration from sessionStorage has completed
In practice this is a single-digit number of milliseconds on cached page loads, and a few hundred milliseconds on cold loads with a slow campaign API.
There is no JavaScript event you can listen to for "all skeletons will now fade." The SDK does emit next:initialized and next:display-ready events on window, but the actual fade is handled by CSS keyed off the next-display-ready class. Don't write JavaScript to wait for it — let the browser do the work.