ISR revalidation intervals: choosing freshness vs rebuild cost for Jamstack product pages

Product pages that show yesterday's inventory

Your e-commerce site is statically generated for speed, but inventory numbers change throughout the day. A full rebuild on every stock update takes too long, and server-side rendering every product page adds latency and cost. You need a middle ground: pages that stay cached at the edge but refresh without rebuilding the whole site.

Setting an ISR revalidate interval

Incremental Static Regeneration (ISR) lets Next.js regenerate individual pages after the initial build. You configure a revalidate interval in seconds. After that interval passes, the next request triggers a background regeneration. The first visitor after the interval may see stale content; later visitors get the fresh version. This is the stale-while-revalidate pattern.

export async function getStaticProps() {
  const products = await fetchInventory();
  return {
    props: { products },
    revalidate: 300,
  };
}

export async function getStaticPaths() {
  return {
    paths: await getProductPaths(),
    fallback: 'blocking',
  };
}

Place this in a page under your Next.js pages directory. The revalidate value is meaningful only on platforms that support ISR, such as Vercel or Netlify. Self-hosted Next.js requires a running server that can accept revalidation requests.

Triggering updates from your CMS

For inventory changes that cannot wait five minutes, add an on-demand revalidation route. Your headless CMS sends a webhook to this route when a product is updated.

// pages/api/revalidate-inventory.js
export default async function handler(req, res) {
  if (req.query.secret !== process.env.REVALIDATE_SECRET) {
    return res.status(401).json({ message: 'Unauthorized' });
  }
  try {
    await res.revalidate('/products/[slug]');
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).json({ message: 'Revalidation failed' });
  }
}

Configure the CMS webhook to POST to this endpoint with the secret token and product path. Protect the route with a secret environment variable so public requests cannot trigger cache purges.

Trade-offs to accept

ISR is not real-time. During the revalidate window, visitors can see outdated inventory. Cold starts during regeneration can slow the first request after the interval. With fallback set to blocking, the first visitor to a brand-new product URL waits for server-side rendering. If you have thousands of product pages, edge cache memory usage grows because multiple page versions may be stored.

For prices or stock levels that must be accurate to the second, use server-side rendering or client-side data fetching instead of ISR.

Verify before you roll out

1. Deploy a product page with revalidate set to 60 seconds.
2. Request the page, wait 60 seconds, then request it again and check the Last-Modified header or content timestamp.
3. Call your revalidation endpoint manually with a valid secret and confirm the response is { "revalidated": true }.
4. Check your platform function logs for cold-start latency on the first post-revalidation request.
5. Inspect response headers such as x-cache or age to confirm the page is served from the CDN cache.

Start with one product category, measure time-to-first-byte before and after enabling ISR, then expand only if the freshness window meets your business requirements.