## Kickstart Next SSG - **Published:** 2026-03-17T11:53:05.495Z - **Updated:** 2026-04-02T11:32:47.063Z - **Tags:** next, react --- This is the Next kickstart to start from when you want the page built ahead of time instead of rendered on every request. It keeps the same Contentstack content model and much of the same rendering logic, but the underlying pattern is static generation. That makes it a good fit for teams who want fast, cache-friendly pages and are happy to treat content updates as a build-time concern most of the time. > This page is a practical developer guide, not a replacement for the official docs. Use it to understand the SSG-specific shape of the project before you decide whether it matches your site. > > ## Watch It First If you want a quick overview before reading through the repo: ## What makes this variant different The SSG kickstart is less about preview mechanics and more about delivery strategy. Its key idea is: - fetch the page at build time - ship a pre-rendered page - keep the runtime simple That makes it meaningfully different from the base Next and SSR variants. It is not just another rendering mode. It teaches a different deployment posture. ## What you get out of the box The current contentstack/kickstart-next-ssg repo includes: - a Next.js Pages Router setup - getStaticProps() for build-time fetching - the Contentstack Delivery SDK - client-side Live Preview support during development - Visual Builder editable fields - the same seeded homepage content model as the other Next kickstarts The Pages Router part is especially worth noticing. Unlike the App Router examples, this one is built around the older but still very understandable static-generation pattern. ## How this specific kickstart works ### 1. pages/index.tsx fetches the homepage at build time The page exports getStaticProps(), which calls getPage("/") and passes the result into the component as staticPropsPage. That is the defining behavior of the kickstart. The first render is based on content that was fetched ahead of time rather than per request. ### 2. The page hydrates from static props, then layers preview on top Inside the component, staticPropsPage becomes the initial React state. After that, the page initializes Live Preview and subscribes to entry changes with ContentstackLivePreview.onEntryChange(...). So the page starts with static content, but in development and preview scenarios it can still re-fetch and update the UI for editors. That is one of the nicest things about this kickstart: it shows how static generation and authoring-friendly preview can coexist. ### 3. lib/contentstack.ts stays close to the base kickstart The Contentstack helper file is familiar if you have already seen the base Next version: - one SDK client - region-aware endpoint handling - preview token support - editable tags in preview mode - a getPage(url) helper The big difference is not the SDK setup. It is when the page asks for data. ### 4. The repo uses the Pages Router on purpose This variant uses pages/ instead of app/. That matters because the kickstart is not just teaching "static output". It is also showing the classic Next.js static-generation shape with getStaticProps(), which many teams still understand well and continue to use in production. ## What you are really learning from this project This kickstart is useful because it teaches the practical trade-off behind SSG: - very fast page delivery - simple runtime behavior - predictable build-time fetching - a cleaner path for CDN-friendly sites At the same time, it shows the main limitation clearly: published content changes are not reflected in a production build until the site is rebuilt or another revalidation strategy is added. ## When to choose this one Choose the SSG kickstart when: - your content changes less frequently than your traffic arrives - you want pages that are mostly built ahead of time - you prefer a simpler static delivery model - you want a minimal example of Contentstack working with getStaticProps() If your page content must be request-fresh on every load, the SSR kickstart is the better fit. ## Fastest way to try it The setup flow is the same familiar pattern: - Seed or reuse the kickstart stack. - Create a delivery token with preview enabled. - Add the stack values to .env. - Enable Live Preview for the same environment. - Run npm install and npm run dev. In development, the page still feels interactive because Next simulates the content-fetching loop in a developer-friendly way. The static-generation idea becomes more obvious once you think about the production build, where content changes normally require another build or a revalidation strategy. ## A good next step after the first run After the homepage works, the most useful follow-up is adding another statically generated route and then deciding how you want content freshness handled later. That is usually the real architectural decision in an SSG project, and this kickstart gives you a clean place to start that conversation.