Keep Jamstack Fast With Incremental Static Regeneration in Next.js

Marketing wants pricing updated today. Engineering wants the site to stay fast and cheap to host. A full rebuild for every copy change breaks both.

The useful takeaway for a Jamstack site on Next.js is to keep pages static at the edge and let Incremental Static Regeneration (ISR) handle freshness per page. You get CDN speed for readers and controlled updates without rebuilding the entire site.

What ISR changes about static delivery

Jamstack relies on pre-rendered HTML served from a Content Delivery Network (CDN). The classic problem is staleness: once a page is built, it remains unchanged until the next full deployment.

ISR adds a revalidation window to a statically generated page. Next.js renders the page at build time using getStaticProps, stores the HTML on the CDN, and serves that cached version instantly to users. After the revalidate interval passes, the next request triggers a background regeneration from your data source. Readers never wait for the rebuild; they receive the last cached static version while a fresh one is produced in the background.

Fallback rendering is handled automatically for paths that were not generated at build time. The first request for a new path can trigger generation, ensuring content is available without requiring a full site build.

Choosing revalidate per route, not globally

Revalidation is configured in getStaticProps with the revalidate property, defined in seconds. This allows you to tune freshness based on the specific data type:

• High-churn marketing copy: 60 to 300 seconds.
• Product catalogs updating hourly: 3600 seconds.
• Legal or policy pages: false or a very large interval.

Short intervals improve freshness but increase origin requests. Long intervals reduce load but widen the staleness window. Monitor request patterns and API latency, then adjust the interval accordingly.

Worked example: pricing page with time-based revalidation

Assume a Next.js project using the Pages Router with a data source at an internal API. The goal is a pricing page that updates within a minute without a manual deploy.

Create pages/pricing.js. Run these commands in the project root with write access to the repository.

// pages/pricing.js
export async function getStaticProps() {
  const res = await fetch('https://api.example.com/pricing')
  const pricing = await res.json()

  return {
    props: { pricing },
    revalidate: 60 // Regenerate page at most once every 60 seconds
  }
}

export default function Pricing({ pricing }) {
  return (
    
      Pricing
      
Current Price: {pricing.amount}
    
  )
}

Deploy the app to an ISR-capable host such as Vercel or Netlify. Plain static file hosting (like a standard S3 bucket) will serve the HTML but will not trigger the background revalidation process.

To verify the result, update the underlying data source, wait for the 60-second window to expire, and refresh the page. The new content should appear without a full site rebuild. You can also inspect response headers for X-Next-Revalidate to confirm the interval is active.

Risk: The fetch in getStaticProps runs on the server during regeneration. Ensure the API can handle bursts when traffic arrives just after the window expires. Implement timeouts and error handling so a failed regeneration does not purge the existing cached page.

Limitations and trade-offs

ISR requires a hosting platform that supports on-demand regeneration; it is not compatible with generic static file buckets. Because users always see a cached version until regeneration completes, there is a maximum staleness equal to the revalidate interval plus regeneration time. For critical, instant updates, pair ISR with on-demand revalidation via a webhook.

Revalidation times are an operational knob. Too short may overload the backend API; too long may serve stale content. Treat these values as configurable parameters based on real-world traffic, not set-and-forget values.

Rollback is not required for changing revalidate values; the change takes effect on the next deployment. If you significantly reduce the interval, expect an immediate increase in origin traffic.

Actionable closing

Pick one high-visibility, frequently edited route and assign it a revalidate interval that matches its edit cadence. Ship it to an ISR-capable host, verify the header and update flow, then monitor origin request rates for one week. Adjust the interval based on actual traffic patterns rather than assumptions.