When Static Is Enough
A practical decision guide for choosing SSG over a full CMS-driven app — and the signals that mean you actually need more than a static site.
- ssg
- astro
- architecture
- cms
- web development
Not every content site needs a dynamic application server. A lot of projects I’ve seen would be faster, cheaper, and easier to maintain as static (or mostly static) sites — if someone hadn’t assumed “CMS” means “server-rendered app for every request.”
Here’s how I decide when static is enough.
Static is enough when…
Content changes on a human schedule. Exhibitions, blog posts, portfolio pieces, company pages — updates are daily or weekly at most. A rebuild (or ISR/on-demand revalidation) is fine.
Most visitors are readers, not operators. Public audience, few authenticated workflows. Forms can post to a serverless function or third-party without hydrating the whole site.
SEO and performance matter more than real-time personalization. Marketing and cultural sites usually win with fast HTML and clear metadata, not per-user dashboards.
Editors can work in a headless CMS. Sanity, Contentful, and similar tools already give you the editing UX. The frontend doesn’t need to be WordPress PHP to feel “proper.”
You probably need more when…
- Content must update instantly for thousands of concurrent editors
- Large parts of the UI are permission-aware and session-specific
- You’re building complex transactional flows (checkout, multi-step apps)
- Real-time collaboration is a core feature, not a nice-to-have
Then a fuller app architecture earns its complexity.
Hybrid is the default middle
Modern SSG isn’t 2015 “generate once a day and pray.” Patterns that keep you honest:
- Static shells + islands for light interactivity (Astro’s model)
- On-demand rebuilds via CMS webhooks
- Server endpoints only for forms, previews, and gated bits
- Client fetch for truly dynamic widgets, not the whole page
Use the server where it helps. Don’t rent one for every pageview of an about page.
The cost people forget
Dynamic stacks cost more than hosting:
- Caching and invalidation bugs
- Plugin and dependency churn
- Security surface on every request
- Slower pages when the origin is having a day
Static (with a clear rebuild story) deletes a lot of that. For portfolios, archives, and many marketing sites, that’s not a compromise — it’s the correct architecture.
A simple litmus test
Ask: If this page were a flat HTML file updated on publish, what would we lose?
If the answer is “almost nothing users care about,” ship static. You can always add dynamic routes later. Starting with a full app “just in case” is how you inherit complexity you never use.