Fast Astro Builds Without Fetching Sanity on Every Visit

You do not have to choose between slow builds and slow reader requests. The useful architecture separates the authoring event from the reader path: build or render content once, cache it near readers, and invalidate it when Sanity says the underlying document changed.

Start with what actually changes

Use static output for stable routes and site structure. Use on-demand rendering only for pages that genuinely need request-time state. For CMS-backed public content, an edge cache can serve rendered pages without a Sanity query on every visit.

Use three independent layers

The content layer is Sanity. The render layer is Astro. The delivery layer is Cloudflare’s edge cache. Treat their freshness rules separately: a new document requires a route to exist, an edit requires the rendered response to be replaced, and a reader request should normally be a cache hit.

Set a deliberate shared-cache policy

export const CACHE_CONTROL =
  'public, s-maxage=3600, stale-while-revalidate=86400'

Choose the numbers from your editorial freshness requirement, not a generic recipe. A shared max age bounds normal staleness; stale-while-revalidate can preserve speed while one request refreshes a response. A signed webhook remains the fast path for important edits.

Invalidate from the publishing event

After a verified Sanity webhook, deploy if the route set changes, then purge the changed article plus indexes, topic pages, feeds, and the sitemap that reference it. Warm the key public pages after the purge. This avoids rebuilding every blog page just because one paragraph changed.

Measure the right trade-off

Track build duration, deploy completion time, cache-hit rate, Sanity request count, and the time between an edit and the reader-facing update. These show whether the bottleneck is rendering, content retrieval, or invalidation—not just whether the site feels fast on one laptop.

Keep Sanity off the normal reader hot path, keep cache invalidation explicit, and use full rebuilds only when the site’s route structure needs them.

For the implementation sequence and signed endpoint, read the Sanity webhook revalidation guide.