Skip to navigationSkip to content
Portrait of Rasmus
Rasmus Johansson

Some thoughts on ISR, and why I use it

ISR stands for incremental static regeneration and is one of several ways to serve content to the client and visitors of your website. It uses static pages and caching to deliver fast performance while enabling the server to use server-side functions to check if the content is stale and needs to be revalidated.

In practice, this means that if I publish a new blog post the first visitor that visits my page after that will not see the new post but in the background the server will check and regenerate the page for the next visitor. In some cases, this wouldn’t be a good approach as the content isn’t always up to date and you can end up with different versions of pages for different visitors depending on caching strategy used by the framework and host.

Next.js makes using ISR incredibly simple, using the getStaticProps hook you can return a revalidate key with a value for how quickly content should be regarded as stale.

javascript
export async function getStaticProps() {
  return {
    props: {},
    revalidate: 1
  }
}

I use it on the pages containing data grabbed from my CMS like the front page, blog, and game-shelf. I do not publish any content that is critical for my visitors to get right away and generally I make sure to check how everything looks once I publish a new post which means the only one visiting the page and seeing an old version is me. The reason I didn’t go the static generated route is that I do not want to have to trigger a redeploy of my code to build the latest blog posts.

For anyone considering using ISR I would suggest thinking about how critical it is for the content to be completely up-to-date at all times and weigh that against the performance benefits of having the pages served statically instead of generated on demand by the server. It all comes down to the use case.