ISR revalidate Boundary: When Does Full Rebuild Cost Outweigh Stale Content?

Jamstack architectures traditionally shift data fetching to build time, but large content sets can make full static rebuilds a deployment bottleneck. Incremental Static Regeneration (ISR) addresses this by regenerating individual pages on demand, yet the transition from full-site builds to per-page revalidation introduces a configuration decision around the revalidate timer in frameworks such as Next.js.

The core tension is that a short revalidation window improves content freshness at the edge but increases origin regeneration load, while a long window reduces build pressure at the cost of serving stale markup. Documentation describes ISR as updating specific static pages without a full rebuild, but the practical boundary for choosing a revalidation period depends on traffic patterns, content update frequency, and origin capacity.

When a site moves from a purely static generation model to hybrid rendering, what measurable signals indicate that ISR is preferred over server-side rendering? How should teams model the tradeoff between stale-while-revalidate behavior and rebuild cost before committing to a timer? Is there a documented threshold where client-side hydration of ISR pages begins to degrade Core Web Vitals?