We've looked at how you can do SSR with next js, where the page is always be rendered, and SST where the page is only rendered during bill time. But what about ISR or incremental static regeneration to demonstrate how it ties into the ecosystem of the other things that we've looked at. Consider a simple page that loads some content from an external API and then renders it out to the screen. Now, even though we make an external call with fetch over here next, yes, we'll assume that that call will always return the same content and therefore only render this page out at will time. If you want this page to be dynamic and always get rendered on the server, then

what we can do is in that fetch call, provide an options object and set cash to no store. These are things that we already know, and the good news is that for ISR, instead of an all or nothing strategy for fetch caching, we can provide a custom next config object, which allows us to set a custom dynamic validation duration in seconds. Here we are saying that this fetch call should be made again if more than 10 seconds have passed since the last call, and we can even see this in the build output. So with these three pages created, let's run a next build. And here you can see that the SSR page is fully dynamic.

The SSG page is fully static, and the ISR page is initially static. However, it will be revalidated after every 10 seconds. To see this in action. Let's start a production buildup for application and look at the logs for when these components are rendered. For the SSG example, we see nothing on the console. That is because this page was only rendered during the build and will not be rendered again. However, for the SSR example, this will always be rendered. So whenever we visit this page or refresh it, we see a new log on the console. And finally for the ISR page, it'll only be rended if at least 10 seconds have passed

since the last rendering, which is what we set as the revalidate duration for our fetch call. So even though we keep refreshing the page, only after 10 seconds have passed does the page render again. Another way to control the incremental static regeneration is to explicitly export a variable called revalidate. From our route module. To demonstrate this, we have a simple page that has absolutely nothing dynamic about it. And even if we use an NPI like date, as far as next year is concerned, this is not considered a dynamic route. And this is something that we also looked in a lesson on static versus dynamic pages.

One option would be to mark this page as fully dynamic with force dynamic. But instead of that, let's opt into incremental static regeneration by exporting a revalidated variable and providing a revalidation duration in seconds. Here we are saying that this page should be revalidated if a request comes in after 10 seconds since the last time it was rendered. And just like before, we can also verify this in the build output. Hey, you can see that this page is initially static, however, it'll be revalidated after 10 seconds. And we can also verify this in the browser even though we are constantly refreshing the page.

It'll only render a new result after at least 10 seconds have passed.