Static Site Generation (SSG) — co to i kiedy ma sens

01Static Site Generation (SSG) to strategia w której każda strona jest renderowana raz (przy build) do statycznego HTML, a potem serwowana z CDN. Brak serwera renderującego per request. Najszybsza możliwa strona.

02Jak to działa: developer odpala `next build` (albo astro build, hugo build). Framework iteruje wszystkie podstrony, dla każdej generuje HTML+CSS+JS, zapisuje do folderu out/. Potem ten folder deployujesz na CDN (Vercel, Netlify, Cloudflare Pages).

03User wchodzący na stronę dostaje HTML z najbliższego edge node CDN (Tokio, Frankfurt, NYC) w 50-200ms. Brak DB query, brak server processing, brak network round-trip do origin.

04Frameworki SSG popularne 2026:

05**Next.js** — universal, najpopularniejszy, generuje SSG/ISR/SSR per route.

06**Astro** — content-focused, multi-framework support (React, Vue, Svelte w jednym projekcie), zero JS by default.

07**Hugo** — najszybszy build (Go), używany dla bardzo dużych stron (10000+ podstron).

08**Jekyll** — Ruby, GitHub Pages default, prostszy ale starszy.

09**Gatsby** — był popularny 2018-2022, dziś w odwrocie (Next.js zjada market share).

10Kiedy używać SSG: blogi, dokumentacja, marketing pages, portfolio, landing pages, strony agencyjne — wszystko gdzie content nie zmienia się per user request.

11Kiedy NIE SSG: dashboardy z user-specific data (potrzebujesz SSR), e-commerce z ciągle zmieniającymi się cenami (lepiej ISR), social network feed (real-time data), formularze z heavy validation server-side.

12Hybrid: Incremental Static Regeneration (ISR) — strona statyczna ale regeneruje się on-demand po update (np. po publikacji nowego posta przez webhook z CMS). Łączy SSG speed z dynamic data freshness.

13Praktyczna rada 2026: zacznij od SSG dla większości stron. Vercel auto-detekuje routes które mogą być statyczne (brak dynamic functions) i prerendeuje je przy build. Sprawdź `next build` output — strony oznaczone jako ○ (Static) są SSG.