SSG, or static site generation, means your website is built into finished HTML files before anyone visits it. A tool runs once during deployment, pulls in your content, and produces a folder of ready-made pages. When a visitor arrives, the server just hands over a file. There is nothing to calculate on the spot.
Think of a print run at a publisher. The book is typeset and printed once, then thousands of identical copies ship out instantly. A static site works the same way: the hard work happens at build time, and every visitor gets the same fast copy. This is the idea behind the JAMstack approach and why frameworks like Astro lean on it so heavily.
The payoff is speed and stability. Plain files can sit on a CDN close to your users, so pages appear almost instantly and your Core Web Vitals tend to look great. Security gets simpler too: with no database or server-side code running on each request, there is far less for an attacker to probe.
The trade-off is the rebuild. Because pages are frozen at build time, changing content means running the build again, which is fine for a blog post but awkward for a price that updates every minute. That is where you mix in SSR or fetch the live bit in the browser. For most marketing sites, blogs, and documentation, the trade-off is easy.
Build time is the other thing to watch. A small site builds in seconds, but a shop with fifty thousand product pages can take much longer, so modern tools rebuild only the pages that actually changed. For a few hundred pages, the whole site rebuilds in a moment and ships straight to the edge.
At TopDevs we default to static generation for content-driven sites, then add server rendering only for the few parts that genuinely need it.
