ISR

Static Site Generation (SSG) builds every page once at deploy time. That is fast for visitors because the CDN serves plain HTML, but the page is frozen until the next build. If you have 754 pages and one fact changes, you either rebuild all 754 or live with stale content.

ISR fixes that. You mark a page with a revalidation time, for example one hour. The first visitor after that hour still gets the old cached page immediately, and Next.js quietly regenerates a fresh copy in the background. The next visitor gets the new one. This pattern is called stale-while-revalidate: serve stale, refresh behind the scenes.

The key idea is that no visitor ever waits for a rebuild. Pages are produced lazily, one at a time, instead of all at once during deployment. A page that nobody visits never gets regenerated, which keeps compute cheap.

In the Next.js App Router you set export const revalidate = 3600 in a page or route segment, where the number is seconds. The framework caches the rendered output (the HTML plus the React Server Component payload and any fetch results) on the server and at the edge.

When a request arrives after the revalidate window has passed, Next.js returns the cached page and triggers a regeneration job. That job re-runs the server component, re-fetches data, and atomically swaps the cache entry. If regeneration fails, the old page keeps serving, so a broken data source does not take the page down.

Beyond time-based revalidation, Next.js supports on-demand revalidation. You call revalidatePath('/lessons/latency') or revalidateTag('courses') from a server action or webhook, and only the affected pages are invalidated. This is how a CMS publish button or a Stripe webhook can refresh exactly the pages that changed within seconds, with no redeploy.

ISR fits content that is read far more often than it is written and where minutes of staleness are acceptable: documentation, course lessons, product catalogs, blog posts, marketing pages. For a learning platform with hundreds of lesson pages, ISR means each page renders once on first visit and then serves from cache for everyone else.

Avoid ISR for content that must be correct to the millisecond, like a stock trading balance or a live auction price. Those want full server rendering or client fetching. Also avoid it for pages that are unique per user, since a shared cache cannot hold per-user state.

The main trade-offs: a visitor can see data that is up to one revalidation window old, and the first request after a deploy or after a cold page may be slightly slower while the initial render happens. On-demand revalidation removes most of the staleness concern but requires you to wire up the triggers correctly.

Imagine an e-commerce category page listing 200 products with prices. Pure SSG would freeze the prices until the next deploy. Pure SSR would hit the database on every single request, which is slow and expensive under traffic spikes.

With ISR you set revalidate to 60 seconds. A flash sale starts and 50,000 shoppers hit the page in a minute. They all get the same cached HTML from the CDN, so the database sees roughly one regeneration per minute instead of 50,000 queries. Prices are at most 60 seconds stale, which is fine for a catalog.

When an admin changes a price, the system fires revalidateTag('products') from the update handler, and the category page plus the affected product page refresh within a second rather than waiting out the 60 second window.