A Practical Architecture for a Fast, Content-First Astro Site

A publishing site should make the article the easiest thing to deliver. Astro is a good fit when most pages are content, navigation is conventional, and only a small part of the interface needs browser-side behavior. The point is not to avoid JavaScript at any cost; it is to make each client feature earn its bytes.

Start with three boundaries: the content model, the rendered page, and the interactions that truly need a browser. A Sanity document can hold structured headings, links, images, and callouts. Astro can turn that document into semantic HTML on the server. A small search bundle or theme toggle can then enhance the page without becoming responsible for its core content.

Render the content where it is needed

For mostly static articles, build-time rendering keeps delivery simple and makes the page available immediately from the edge. If content changes frequently and a rebuild is too slow, an on-demand route with Incremental Static Regeneration can cache the rendered response and refresh it after a signed CMS webhook. Select that mode deliberately: it adds a server runtime, secrets, cache behavior, and operational tests.

Keep pages usable with JavaScript disabled. Search may need a small client script, but the article title, body, author, canonical URL, and metadata should already be in the HTML. Avoid hydrating an entire application merely to open a navigation menu or switch a color theme.

Keep content structured, not entangled with layout

Use a content model that editors can understand: required title and slug, a short excerpt, a publish date, clear categories, and a constrained body block set. Validate important SEO fields in the Studio, then still render robust fallbacks in the site. A required image alt field is useful, but writers also need guidance on when an image is informative versus decorative.

Share types for the shape of a post card and a full article, and keep GROQ projections explicit. Fetching only the fields a page uses makes the query easier to review. Treat a failed content request as an error worth surfacing; silently replacing a failed API response with an empty list makes a broken production deploy look like a successful empty site.

Make caching and publishing observable

If using ISR, decide which routes should be cached, how long a response is fresh, and what a publish, update, delete, or unpublish event invalidates. A webhook should authenticate its sender, validate the payload, map only known slugs to routes, and report any failed revalidation request. Keep the route invalidation list in one place so home, category, author, article, and sitemap views stay consistent.

export default defineConfig({
  output: 'server',
  adapter: vercel({
    isr: {
      expiration: 60 * 60 * 24,
      bypassToken: process.env.VERCEL_REVALIDATE_TOKEN,
    },
  }),
})

Measure the result, not just the build

After a deploy, inspect the generated or rendered HTML, test a post URL and a missing slug, run the search interaction, and verify the canonical, Open Graph image, structured data, sitemap, and RSS output. Track field performance after real visitors arrive. A fast build is not proof that a reader-facing page is fast.

Astro’s content collections and rendering guides are good references for the framework side. Keep the architecture small enough that the next editor and maintainer can understand how an article travels from draft to page.