Stagger Orchestration

When to use this

• Revealing a list of cards, nav items, or text lines with cascading delay.
• Animating a grid of items with directional or ripple-from-center stagger.
• Coordinating entrance stagger across nested groups (e.g., a section title, then its cards, then a CTA).
• Tuning stagger timing so it reads as choreography, not a loading bug.
• Do NOT use this for scroll-triggered reveals specifically; see scroll-reveal-choreography for IntersectionObserver-based patterns.

Mental model

Stagger is not "delay each item by X ms." Stagger is a total duration budget distributed across N items. The distinction matters because N * perItemDelay grows linearly. 5 items at 80ms each is 320ms total, which feels snappy. 20 items at 80ms each is 1.6 seconds, which feels like something is broken.

Professional stagger works backward from the total duration budget, not forward from per-item delay. Decide "I want this group to finish revealing in 400ms." Then divide: perItemDelay = totalBudget / (N - 1). For 5 items, that is 100ms each. For 20 items, that is 21ms each. The result: the group always takes the same time regardless of item count, and each individual delay adjusts.

GSAP's stagger property understands this natively with { each: 0.08 } (fixed per-item) vs { amount: 0.4 } (total budget). Always prefer amount for lists of variable length.

For 2D grids, stagger direction matters. from: "start" staggers top-left to bottom-right. from: "center" radiates outward. from: "edges" converges inward. The grid parameter tells GSAP the grid dimensions so it calculates 2D distance correctly rather than just using flat index order.

Stagger across nested groups requires manual orchestration. The section title reveals first, then after a short delay the cards begin their staggered reveal, then the CTA appears at the end. This is a timeline, not a single stagger call.