Skip to main content

Render Strategies

Why we should choose to use Incremental Static Regeneration with a Headless CMS?​

Each project could be various scales and bigger scale projects tend to have more challenges to solve. If your projects are distributing their markets on a global scale, the amount of the content tends to be bigger.

One of the common concerns for such cases is building time.

The idea behind the Jamstack is appealing: pre-rendered static pages which can be pushed to a CDN and globally available in seconds. Static content is fast, resilient to downtime, and immediately indexed by crawlers. But there are some issues.

If you’ve adopted the Jamstack architecture while building a large-scale static site, you might be stuck waiting hours for your site to build. If you double the number of pages, the build time also doubles.

Static Site Generation

Pros and cons between SSR, SSG, and ISR​

We are already bought into the headless approach. Now it is time to compare the different data fetching / rendering strategies we have available.

Server Side Rendering (SSR)​

Pros: Pages are always updated whenever being reloaded. Hence, it's quick to have initial access to pages. Good for SEO.

Cons: Performance will be low and need to deal with caching issues. SSR by default is often slower than SPA and SSG. Also, more API calls are required because the page HTML is generated in each request.

Static Site Generation (SSG)​

Pros: Fast performance and the security attack on a static website can be minimized. Fewer API calls.

Cons: Pages are generated at build time. It means until the next build, page content will stay the same. Longer build time with more pages.

Incremental Static Regeneration (ISR)​

Pros: Possible to choose the number of pages to generate with an adjustable stale time with revalidate. Really fast performance with less build time.

Cons: There's still stale time in the beginning.

Server Side Rendering (SSR) was popular in a monolithic world. In a Jamstack world, Static Site Generation (SSG) was applied often. Yet, both approaches had concerns, such as performance, caching, and long build time.

Incremental Static Regeneration (ISR) was created to find a hybrid and better solution by Next.js.

The whole concept is that to enable static-generation on a per-page basis without rebuilding the entire site.

Consider an website with 100,000 content pages. At a realistic 50ms to statically generate each content page, the build would take almost 2 hours without ISR. With ISR, we can choose from:

  • Faster Builds → Generate the most popular 1,000 content pages at build-time. Requests made to other content will be a cache miss and statically generate on-demand: 1-minute builds.

  • Higher Cache Hit Rate → Generate 10,000 content pages at build-time, ensuring more content is cached ahead of a user's request: 8-minute builds.

Incremental Static Regeneration

Fetching Data​

ISR uses the same Next.js API to generate static pages: getStaticProps. By specifying revalidate: 60, we inform Next.js to use ISR to update this page after it's generated.

Incremental Static Regeneration

  1. Next.js can define a revalidation time per-page (e.g. 60 seconds).
  2. The initial request to the content page will show the cached page.
  3. The data is updated in the CMS.
  4. Any requests to the page after the initial request and before the 60 seconds window will show the cached (hit) page.
  5. After the 60 second window, the next request will still show the cached (stale) page. Next.js triggers a regeneration of the page in the background.
  6. Once the page has been successfully generated, Next.js will invalidate the cache and show the updated content page. If the background regeneration fails, the old page remains unaltered.
// pages/stories/[slug].js

export async function getStaticProps({ params }) {
  return {
    props: {
      story: await getStoriesFromContentful(params.id),
    },
    revalidate: 60,
  };
}