Astro 7.2 can skip unchanged static pages instead of rebuilding them all

Astro 7.2 introduced an experimental incremental static-build mode. Previously Astro regenerated every prerendered page on each build. Opted-in routes can now return a per-path `cacheKey`; Astro also hashes the route’s complete module graph. A page is reused only when both the code hash and its data cache key match the previous build.

For large static sites, generation can dominate build time even after bundling has been optimized. This gives Astro projects a framework-native way to avoid rendering thousands of unchanged pages, potentially reducing CI duration and deploy latency without switching to runtime rendering. The trade-off moves some correctness responsibility to builders: a stale or incomplete cache key can reuse output that should have been regenerated.

Astro 7 already accelerated bundling with Rolldown and Rust-based content processing, but the framework still rendered every prerendered route on every build. Astro 7.2 targets that remaining generation work. When `experimental.incrementalBuild` is enabled, a dynamic prerendered route can provide a `cacheKey` for each generated path. Astro separately hashes the route’s full module graph — including templates, layouts, components, imported assets and package code — and only reuses a prior page when both code and data signals are unchanged.

Routes without a cache key continue to render every time, so existing projects do not silently change build behavior. Astro stores incremental-build state in its cache directory, `node_modules/.astro/` by default. CI environments therefore need to persist that directory across builds; otherwise the framework has nothing to reuse and the optimization disappears.

Astro can detect code changes automatically, but application data is represented by the builder-supplied cache key. Content collections expose an entry digest that fits this model, but routes drawing from APIs, databases or multiple content sources need a key that changes whenever any rendering input changes. An incomplete key can produce stale static output, so teams should treat cache-key design as part of build correctness rather than only as a performance tweak.

The same release can remove unused session runtime from SSR bundles, adds background mode to `astro preview`, and aligns preview-server control with the background workflow introduced for `astro dev`. Those changes are useful, but incremental generation is the development with the clearest architectural consequence for large static deployments.