Static site generation (SSG)

Why it is fast and cheap

A static file has no work to do. There is no template to render, no query to run and no server process to keep warm, so the response is a file read from a CDN edge near the user. That removes the two things that usually make a page slow — server response time and database latency — and it removes most of the operational surface at the same time: nothing to patch, nothing to scale, no connection pool to exhaust under traffic.

It also makes hosting close to free. Firebase Hosting, Netlify, Cloudflare Pages and GitHub Pages all serve static output on generous free tiers.

Where the content comes from

The data is fetched at build time rather than at request time. A generator reads markdown files, a headless CMS or an API, renders every page, and writes the output. NorthernGo's own site is built this way: the glossary and guides are source files that the build turns into one HTML file per page and per language.

That timing is the whole trade-off. Content is only as fresh as the last build. A price change or a new article requires a rebuild and a redeploy — usually seconds to minutes, but it is a step. Sites with thousands of pages also feel build time directly, which is why incremental and on-demand regeneration exist in frameworks like Next.js and Astro.

What static cannot do, and what it can

Anything personalised per visitor cannot be baked in. A logged-in dashboard, a shopping cart, a per-user feed — those need to be fetched in the browser after load, or rendered on a server.

But "static" refers to how the HTML is produced, not to whether the page is interactive. A static page can still run JavaScript, call an API, take payments and update live. This is the common misconception: static site generation is not the same as a static, brochure-like website. Most modern sites are static shells that fetch dynamic data.