Two Strategies for Incremental Site Builds

For sites that rely on pre-built pages, deployment means compiling everything up front — JSX to JavaScript, SCSS to CSS, templates to HTML. As a site grows, that process gets slow. One way to handle it is incremental building: split the pages into critical ones that are built at deploy time and deferred ones that are built later.

  • Type A ("Critical" pages): home page, about us, contact us.
  • Type B ("Deferred" pages): product catalogs, some documentation, anything hit less often.

Both Incremental Static Regeneration (ISR) and Distributed Persistent Rendering (DPR) follow this pattern. Both build Type A pages upfront. Where they differ is how Type B pages are handled — and more importantly, what happens after those pages exist.

Immutability Is the Dividing Line

The key difference between ISR and DPR is immutability: once a page is part of a build, does it ever change for that deployment?

With ISR, Type B pages are generated at runtime when a user first visits them. Each page carries an expiration (or revalidation) time, after which it re-builds in the background with fresh content. This is a "stale while revalidate" caching model: a page can serve old data for a while, then get replaced when the updated version is ready.

The major downside: ISR does not guarantee immutability across builds. You can't roll back to an earlier deployment and expect every page to show exactly what it showed then. That makes debugging harder, since different users may see different versions of the same page. On the plus side, content can change without a full site rebuild.

DPR also builds Type B pages on first request, but once built, those pages are cached at the edge permanently — until the next deploy. That guarantees immutability: every visitor to a URL sees the same data during that deployment. The trade-off is that updating such a page requires triggering a site rebuild.

Trying Both Approaches Yourself

Right now, the easiest way to compare them is with Next.js. ISR is built into Next.js by default when deployed to a Node.js platform like Vercel. DPR, meanwhile, is what you get when deploying to Netlify.

DPR is not limited to one framework — Zach Leatherman has demos of deferred builds in Eleventy that skip building hundreds of pages up front. The Next.js team has also said ISR will reach other frameworks, including Nuxt and SvelteKit. There's also an open RFC for DPR implementations on any Jamstack platform worth reading if you're considering building your own.