Build Strategy

Baan’s build strategy controls how blog post pages are rendered and cached. The right choice depends on how often you publish and how quickly updates need to appear for readers.

The Three Strategies

Strategy	Build Time	Time-to-first-byte	Content Updates	Best For
ISR (default)	Fast	Fast (cached after first hit)	Near-instant on save	Most blogs
SSG	Slow (scales with post count)	Fastest (fully pre-rendered)	Requires rebuild + redeploy	Small sites, rarely updated
SSR	Fast	Slower (rendered per request)	Instant, always fresh	High-traffic sites with CDN

---

ISR — Incremental Static Regeneration (Default)

How it works: Pages are rendered on the first request and cached. When you save a post in the admin panel, Baan calls revalidatePath() on that page’s cache, so the next request gets a fresh render. Subsequent requests hit the cache again. Images in articles are served via a proxy endpoint (/api/image) that also maintains a 24-hour server-side cache — this cache is invalidated alongside the page cache on every save.

Result: Readers always see content that is at most one request stale after a save. In practice, updates appear within seconds.

Best for: The vast majority of blogs — you get static-site performance without the deploy-every-time workflow.

Tip

ISR is the recommended strategy for most Baan users. You get the speed of static rendering with the convenience of instant updates.

---

SSG — Static Site Generation

How it works: Every post page is pre-rendered at build time. The output is a set of static HTML files that can be served from a CDN with no server-side processing at all.

Result: The fastest possible time-to-first-byte, but any update (new post, edit, publish/unpublish) requires running npm run build again and redeploying.

Best for: Sites with a small number of posts that rarely change — documentation, portfolios, or archival sites where you batch-publish on a schedule.

Caution

With SSG, unpublishing a post requires a rebuild before it disappears from the site. Don’t use SSG if you need updates to appear quickly.

---

SSR — Server-Side Rendering

How it works: Every request triggers a fresh render on the server. There is no page cache — the server reads content from storage and renders HTML for each visitor.

Result: Content is always up-to-date for every visitor, but each request costs server resources. Pair this with a CDN (Cloudflare, Vercel Edge) that caches at the edge to get the best of both worlds.

Best for: Sites with very frequent content changes, personalized content, or when you want to place a CDN cache in front and control caching headers yourself.

---

How to Change the Strategy

Go to Admin → Settings → Build, select a strategy, and save. No restart required for ISR and SSR. SSG takes effect on the next build.

The default is ISR.

Note

Changing from SSG to ISR or SSR takes effect immediately. Changing to SSG requires running npm run build to pre-render all pages.