Performance
Incremental static regeneration
Also called ISR.
Incremental static regeneration is serving a prebuilt static page while a fresh one is built in the background after a set time. Visitors get static speed, and content updates without a full rebuild.
How it is measured
After the revalidate window passes, the first request still gets the stale page, which triggers a rebuild. The next visitor gets the new one. Check the cache header, such as `x-nextjs-cache: STALE`, and the `age` value.
Time to first byte for the stale response is that of a static file. The regeneration happens off the request path, so its cost shows up on the server, not in the visitor's TTFB.
Worked example
A recipe site sets `revalidate: 600` on its article pages. At minute 11 a reader gets the 10 minute old page with TTFB of 60 ms, and the server regenerates in 1,400 ms in the background. The next reader sees the updated recipe, also at 60 ms.
A page with no traffic for an hour stays stale until someone asks, so an edit made at 9:00 may not appear until the first visit at 10:20.
How it differs
Incremental static regeneration updates static pages on a timer or on demand. Static site generation builds everything once at deploy. Stale-while-revalidate is the HTTP pattern that ISR resembles. ISR trades a short freshness delay for fast reads.
Common errors
Treating the timer as exact freshness. Using it for personalized pages. Forgetting on-demand revalidation for urgent fixes. Setting revalidate to a few seconds on a huge site and creating a regeneration storm. Not caching the HTML at the CDN.
In practice
Pick a revalidate time that matches how often the content changes, and wire a webhook to revalidate on publish. Check the cache header on a few URLs to confirm the stale and fresh states.