Sriram Thiagarajan
Published on

Next.js' ISR vs Gatsby's DSG

When I heard about Gatsby adding a new rendering option called Deferred Static Generation in Gatsby 4, I thought it’s similar to Next.js’ Incremental Static Regeneration. Looking a bit deep into the DSG rendering option, it turns out there are quite a few differences. Hint: if you look closely at the names, you might be able to guess what the main difference is :)

Let’s see each of these options in detail.

Deferred Static Generation

From the docs - Deferred Static Generation is developers can choose to defer building certain pages until the first time a user requests it.

This essentially means we’re delaying the generation of the page until the first request. Once the page is generated, all subsequent users will see the same page from cache.

Incremental Static Regeneration

From the docs - Next.js allows you to create or update static pages after you’ve built your site. Incremental Static Regeneration (ISR) enables you to use static-generation on a per-page basis, without needing to rebuild the entire site. With ISR, you can retain the benefits of static while scaling to millions of pages.

The key to note here is “create or update”. Next.js ISR will be able delay the generation of a page until first request, and also be able to regenerate the page after a specific time has elapsed.


As you would have seen from the above details, the main difference between ISR and DSG is that ISR will be able regenerate your page on a given interval. Once a page is generated, it’ll be served from cache till the time it is regenerated and the regeneration happens in the background. This is really powerful as the page regeneration will be able to fetch updated data from your data source.

In contrast, DSG is just delaying the generation of static pages. Once a page is generated (upon first request), it’s just static. If you update the content for the page after it’s generated, you’ve to run the build once again to invalidate the cached page.

The problems that ISR & DSG solve are also different. DSG solves the problem of having a longer build times. This has been a problem with Gatsby for a while. More the number of pages, more the build time. And DSG is a pretty good option to solve this as you can build the logic yourself whether you want to generate a page at build time or not.

ISR, to me, seems like a superset of DSG - you can still do deferred generation of static pages, and also regenerate those pages automatically when the given time elapses. For example, if you have page with some data source that gets updated on a daily basis, you can set Next.js to regenerate the page every day. So your users will still be accessing static page from CDN & you get all the speed benefits, and at the same time you don’t have to run the build process everyday.

Furthermore, pages generated by ISR are persisted across deployments (at least on Vercel) i.e. your users will see the cached version of the page even if you deploy a new version of your code. The page will only be regenerated based on revalidate option in your code. For more details, look at Vercel’s documentation.

Okay, this is my understanding of these two and if you find something is wrong, please let me know on twitter. Feel free to tweet / DM if you want to talk about this in more detail or just wanna say hi :)

PS: I’m quite sure something like ISR will be coming to Gatsby in near future

Discuss on