Static site generation

Static site generation is a rendering strategy where every page of a website is built into a plain HTML file at build time. The file is then uploaded to a CDN or file server and served directly to any browser that asks for it. There is no server process on the critical path. Every visitor gets the same pre-built file. ## How SSG works A static site generator takes source files (Markdown, MDX, JSON, a database query result) and templates, and produces one HTML file per page in the site. The build runs once, either locally or in CI. The output is a folder of HTML, CSS, JavaScript, and images. That folder is deployed to a host that serves static files. At runtime, the host does no work beyond serving the correct file. There is no database query, no template rendering, no application logic. The browser downloads the file, runs any JavaScript included with it, and displays the page. ## SSG vs SSR Static generation and server-side rendering both produce HTML on the server, but at different times. SSG produces HTML once at build time. SSR produces HTML on every request. SSG is cheaper and faster at runtime because there is no per-request work. SSR is more flexible because it can include data that changes between builds. The practical difference shows up when data changes. A static site with a product catalog needs a rebuild every time a product changes. A server-rendered site fetches fresh data on each request. For a marketing site or blog, that rebuild is fine. For a busy ecommerce catalog, rebuilding thousands of pages every time an inventory count changes is impractical. ## Incremental static regeneration Modern frameworks blur the line between SSG and SSR. Next.js has incremental static regeneration (ISR). Nuxt has similar patterns through hybrid rendering. The frontend renders a page statically, then re-renders it in the background when it becomes stale. Visitors get static-fast responses most of the time and only occasionally hit a live rebuild. The pattern makes SSG viable for content that changes but does not change every minute. ## SSG in ecommerce Pure static generation is rarely used for full ecommerce sites. Product pages, cart, and checkout need live data. But SSG works well for the parts of the site that change less often: category shells that render on top of live product data, marketing landing pages, campaign pages, blog posts, help articles, and legal pages. A well-designed ecommerce frontend uses SSG for those and reserves SSR for pages that need per-request data. ## How Frntkey relates Frntkey uses a hybrid of SSR, static generation, and edge caching. Pages that change constantly (product listings, product detail, cart, checkout) are server-rendered on Vercel. Marketing pages authored in Storyblok are statically generated and revalidated on content changes. Cached responses are served from Vercel's edge, so most visitors get static-fast responses without giving up freshness. The mix keeps Core Web Vitals green and hosting costs predictable. ## Related terms Server-side rendering · Jamstack · Core Web Vitals · Ecommerce frontend