What is ISR in Next.js, and how is it different from a static page or rendering on every request?

The interviewer wants to know that you understand the three ways to build a page and can choose the right one for each kind of content, rather than only knowing the abbreviations.

There are three ways. A static page (SSG) is built once at build time and stays as it is, so it is very fast but only changes when you redeploy. Rendering on every request (SSR, or dynamic) builds a fresh page each time someone views it, so it is always up to date, but every view costs one round of processing and data queries. ISR (incremental static regeneration) sits in between: the page is stored like a static page, and Next.js rebuilds it in the background in one of two ways.

1. By time. Set export const revalidate = 60 and after 60 seconds the next request still gets the old version but triggers a rebuild. When the new version is ready, later requests get it. This means readers never wait for data.
2. On demand. When content changes, the code calls revalidatePath or revalidateTag to mark the cache as expired, and the next visit rebuilds it.

How to choose: content that rarely changes and has many readers, like blog posts or product pages, suits ISR. Content specific to each user, like an account page, needs rendering on every request. Content that never changes, like an about page, suits a static page.

Two more points to add. One is the trade-off: ISR lets readers see an old version for a short time, so it doesn't suit data that must be accurate to the second, such as stock levels or balances. The other is that if you use a route to refresh on demand, you have to protect it with a secret, otherwise anyone can call it and force the server to rebuild again and again.

Bonus points: say that ISR needs a running Node.js server, so you can't use it when you export the blog as fully static HTML files.