Static site generator (SSG)

With static generation, the work of turning content and templates into HTML happens once, when the site is built, rather than every time someone visits. The output is a folder of HTML, CSS, JavaScript and images that any CDN can serve. Astro, Hugo and Eleventy are built around this model, and Next.js can export a fully static site as well. Astro prerenders the whole site by default and lets individual routes opt into on-demand rendering when they need a server.

Google’s web.dev guidance notes that static rendering gives a consistently fast time to first byte, because no HTML is generated on the server per request, and a fast first paint as long as client-side JavaScript stays small. The limit is that a page must exist for every URL at build time, which does not work when URLs cannot be known in advance.

Why it matters for a SaaS website

Most of a SaaS marketing site is the same for every visitor: product pages, pricing, case studies, docs, blog posts. Building those pages ahead of time makes them fast from anywhere, cheap to host and hard to break, with no database or server-side plugins exposed to attack. Crawlers and AI tools receive complete HTML, which helps both search and answer engines read the page.

The trade-off is that content changes need a rebuild. On a site with thousands of pages, build times and preview workflows need planning.

How DesignMe handles it

We build code-based marketing sites as mostly static, and add server rendering only where a route needs it. For fintech and healthtech teams we often recommend a static Astro site because it ships few third-party scripts and leaves a small attack surface. Content sits in typed content collections or a headless CMS, and our own website runs the same way: built in Astro and edited through Claude, with every change reviewed before it goes live.

Example

Say a healthtech company’s WordPress site runs 25 plugins and needs monthly security patches. Rebuilt as a static Astro site, its 90 pages become HTML files on a CDN. Clinical content lives in a headless CMS, and publishing a change triggers a build that finishes in under a minute. The contact form posts to a form service, and the only server-rendered route is a status page that reads live data.

Common mistakes

• Shipping a JavaScript app anyway. A static build that hydrates every component loses most of the speed benefit.
• Rebuilding everything for one typo. On large sites, set up incremental builds or on-demand routes for content that changes often.
• No preview for editors. Editors need to see drafts before a build publishes them.
• Forcing dynamic pages into static. Logged-in dashboards and per-user pricing belong on the server.