A static site generator (SSG) is a build tool that turns templates and content files into finished HTML pages before anyone visits your site. The server then hands out those ready-made files instead of assembling each page on request. SSGs suit sites whose content changes on a schedule you control, such as brochure sites, blogs and documentation. They are a poorer fit where every visitor needs a different, live page.
How a static site generator works
You keep content in files (commonly Markdown) and layout in templates. At build time the generator combines them and writes one HTML file per URL into an output folder. That folder is uploaded to a host or content delivery network.
Eleventy’s documentation describes exactly this model: it turns template files into web pages when you build, and the finished static files land in an output folder (_site by default). It accepts many template languages, from Markdown and Nunjucks to JavaScript and WebC (Eleventy documentation).
Hugo, built in Go, focuses on build speed and says it renders a complete site in seconds, often less. It also ships with multilingual support and a taxonomy system for categories and tags (Hugo introduction).
Astro began as a static site builder and was designed for content-rich websites. It renders HTML on the server as much as possible and ships less client-side JavaScript, letting you opt in only for components that need it (Astro: Why Astro).
Why teams choose static output
Google’s web.dev explains the performance logic. Because static pages are built ahead of time, first paint is fast and server response time is consistent. If client-side JavaScript is kept limited, Total Blocking Time and Interaction to Next Paint stay low, and the HTML can be cached at the edge on multiple CDNs (web.dev: Rendering on the Web).
Practical benefits that follow from that design:
- Speed: there is no database query or template execution while the visitor waits. See website speed and Core Web Vitals for what that means for users.
- Smaller attack surface: a public site made of plain files has no admin login or plugin code running on the live server. That is a reasoned consequence of the architecture, not a guarantee of security.
- Simple hosting: files can sit on almost any host.
- Version control: content and code live together, so changes are reviewable and reversible.
Where static generation falls short
The same web.dev page is candid about limits. Static rendering must generate an individual HTML file for every possible URL, which becomes hard when URLs are unpredictable or the site has a very large number of pages. It handles personalised or live data poorly, where server-side rendering is the better tool. The trade-off is flexibility for speed and cacheability, and you can mix both approaches on one site.
Other honest limitations:
- Editing experience: non-technical staff may expect a visual editor. Without one, every change goes through files and a rebuild. A headless CMS can solve this but adds a service to manage.
- Rebuild time: large sites need a rebuild to publish a change.
- Dynamic features: forms, search, bookings and logins need third-party services or small server functions.
SSG or CMS: a quick decision guide
| Question | Leans toward an SSG | Leans toward a traditional CMS |
|---|---|---|
| Who edits content? | A developer or technical editor | Several non-technical editors |
| How often does it change? | Weekly or less | Many times a day |
| Is personalisation needed? | No | Yes |
| What matters most? | Speed, low maintenance | Plugin ecosystem, familiar admin |
| Page count | Tens to thousands | Very large, frequently changing catalogues |
If you are weighing a specific platform, Astro versus WordPress works through the comparison. If you have chosen Astro, content collections are the built-in way to manage articles.
Choosing an SSG
- List the page types and who maintains each.
- Decide how content will be edited: files, Git-based editor or headless CMS.
- Check the generator’s language fits your team (Go for Hugo, JavaScript for Eleventy and Astro).
- Prototype one template and one content type before committing.
- Confirm where forms, search and analytics will come from.
Where Radiance Impact fits
Radiance Impact’s Technology division builds business websites and landing pages, including static and Astro-based sites. If you are deciding between a generator and a CMS, get in touch or see the Technology page.
Sources
- Eleventy documentation, Eleventy
- Introduction to Hugo, Hugo
- Why Astro?, Astro Docs
- Rendering on the Web, web.dev (Google)
