Vercel ISR Problem: Excessive CMS Requests

[ya2s]

I’m hosting a Next.js application on Vercel. I’m using ISR (Incremental Static Regeneration) with the pages router, and fetching data from a CMS within getStaticProps. I’m having trouble with a large number of requests hitting the CMS immediately after deployment due to cache invalidation. Specifying all pages in getStaticPaths isn’t feasible because the total number of pages is too large. What’s the best approach in this situation?

[pawlean (Pauline P. Narvas)]

Hi, @ya2s! Welcome to the Vercel Community

For large-scale Next.js applications using ISR on Vercel with too many pages to specify in getStaticPaths, you could consider implement on-demand revalidation, i.e. use res.revalidate() in an API route to update specific pages when your CMS content changes, rather than invalidating all pages at once.

Or generate only the most important or frequently accessed pages at build time, and use fallback: 'blocking' for the rest:

export async function getStaticPaths() {
  const mostImportantSlugs = await fetchMostImportantSlugs()
  return {
    paths: mostImportantSlugs.map((slug) => ({ params: { slug } })),
    fallback: 'blocking',
  }
}

Another approach would be to implement caching strategy to serve stale content while revalidating in the background, reducing the immediate load on your CMS.

Let us know how you get on!

Also wanted to share this ISR post recently for anyone passing by

Why should I care about ISR in Next.js?

Have you heard about ISR but don’t get what all the fuss is about? Let’s breakdown some of the common scenarios where ISR can be especially useful. Incremental Static Regeneration (ISR) is a hybrid rendering method that allows teams to get the best of both worlds when it comes to static and dynamic rendering. Most users experience the speed of a cached static page while editors don’t need to wait for a full rebuild of their app to make changes. Publish fast, load even faster with revalidateP…

[ya2s]

Thank you for your response. I’m very happy about it.

Strictly speaking, even when using ondemand-revalidate, if you have not generated pages with getStaticPaths, immediately after deployment (immediately after release), the cache is purged and does not exist for all pages. Therefore, if a large number of accesses come in before the cache is generated, will the number of accesses to the CMS not increase?

Also, if an error is returned from the CMS during that time, the cache will not be generated and the CMS will be accessed for all requests.

In the case of an error, you can return notFound in getStaticProps and cache it, or display the content at the time of the error and cache it, but neither is good from an SEO perspective because 404 or 200 is returned.