Choosing Between SSG and ISR for Jamstack Content Delivery

The Scaling Wall: Build Times vs. Content Freshness

In a Jamstack architecture, the primary goal is to move rendering from the server to the build step. However, as a site grows from 10 pages to 10,000, you encounter a critical bottleneck: the build time. If every content change requires a full site rebuild, your deployment pipeline becomes a liability, delaying critical updates and increasing CI/CD costs.

The decision rests on whether your site can tolerate a full rebuild for every change (Static Site Generation) or if you need to update specific pages on-demand without a global deployment (Incremental Static Regeneration).

Comparison of Fetching Strategies

The following table compares SSG and ISR based on typical Jamstack framework behaviors (such as Next.js or Nuxt). Note that ISR is a framework-level feature and requires a compatible hosting environment to persist the generated HTML cache.

Engineering Trade-offs

When to stick with SSG

SSG is the safest choice for documentation sites, marketing landing pages, or small blogs. Because the entire site is generated at build time, you have a guarantee that every user sees the exact same version of the site. There is no risk of "partial updates" where a homepage reflects new data but a sub-page still shows old data.

When to migrate to ISR

ISR is essential for e-commerce catalogs or large-scale news sites. If you have 5,000 product pages, updating the price of one item should not trigger a 20-minute rebuild of the other 4,999 pages. ISR allows you to define a revalidate window, telling the server to serve the cached version while triggering a background update if the timer has expired.

The "Stale-While-Revalidate" Risk

The primary trade-off with ISR is that the first user to visit a page after the revalidation period expires will still see the stale content. The update happens in the background; only the second visitor (and subsequent users) will see the fresh content. If your application requires absolute real-time accuracy (e.g., stock trading or flash sales), ISR may be insufficient.

Implementation Example: Next.js ISR

To implement ISR, you modify the data fetching function to include a revalidation timer. This example assumes a Next.js environment running on a compatible provider like Vercel or a custom Node.js server.

// pages/products/[id].js

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/product/${params.id}`);
  const product = await res.json();

  return {
    props: { product },
    // Re-generate the page at most once every 60 seconds
    revalidate: 60,
  };
}

export async function getStaticPaths() {
  // Use 'blocking' to generate pages on-demand rather than at build time
  return {
    paths: [],
    fallback: 'blocking',
  };
}

Execution and Permissions

• Where to run: This code runs on the server-side during the build process and subsequently on the production server/lambda function.
• Permissions: The server must have outbound network access to the API endpoint.
• Placeholders: Replace https://api.example.com/product/ with your actual CMS or database API.
• Risk: Setting revalidate to a very low number (e.g., 1 second) can overwhelm your backend API with requests if you have high traffic.

Validating the Result

To verify that ISR is functioning correctly without triggering a full site redeploy:

1. Deploy the site with a revalidate timer of 60 seconds.
2. Visit a specific page and note the content.
3. Change the data in your CMS/Database.
4. Refresh the page immediately. You should still see the old content (this is expected behavior).
5. Wait 61 seconds and refresh again. The page should trigger a background regeneration.
6. Refresh one more time. You should now see the updated content.

Limitation: ISR is not a browser feature; it relies on the server's ability to cache and regenerate HTML. If you deploy to a basic static host (like GitHub Pages) that only supports raw HTML/CSS/JS, ISR will not work, and the site will effectively behave as SSG with no updates until the next push.