SSG (Static Site Generation) polega na wygenerowaniu HTML wszystkich stron jednorazowo, w momencie builda (wdrożenia), i wepchnięciu ich na CDN, który podaje je bezpośrednio użytkownikom. Brak serwera aplikacyjnego, brak bazy danych odpytywanej w locie, brak obliczeń przy każdym zapytaniu: tylko pliki statyczne. To rdzeń podejścia Jamstack, natywnie wspierany przez Next.js, Astro, Hugo, Gatsby czy Eleventy.
Korzyści są ogromne dla stron, których treść nie zmienia się przy każdej wizycie: blog, wizytówka, dokumentacja, landing pages SEO. LCP spada poniżej sekundy, CLS zostaje na zerze, koszt hostingu Vercel/Cloudflare pozostaje darmowy aż do sporych wolumenów. Bezpieczeństwo też jest doskonałe: bez wykonywalnego serwera nie ma czego włamywać. Dlatego stosujemy SSG domyślnie przy stronach na zamówienie marketingowych.
Historyczne ograniczenie — czas builda eksplodujący powyżej kilku tysięcy stron — zostało obejście przez ISR (Incremental Static Regeneration) w Next.js oraz incremental builds w Astro/Gatsby. Dziś można serwować 50 000 stron SEO programmatic w trybie hybrydowego SSG bez pełnego rebuilda. Gdy treść musi być ściśle spersonalizowana per użytkownik, przechodzimy na SSR. Ale dla wszystkiego publicznego i indeksowalnego SSG pozostaje najlepszym kompromisem wydajność/koszt/SEO w 2026.
Kiedy SSG jest właściwym wyborem
- Publiczne, indeksowalne strony: blog, wizytówka, landing, dokumentacja — wszystko, co ma być serwowane z CDN.
- Przewidywalny wolumen treści: do 50 000 stron z Next.js + ISR, powyżej wciąż możliwe, ale wymaga architektury.
- Krytyczna wydajność: Core Web Vitals na zielono bez optymalizacji, wyniki Lighthouse 95+ domyślnie.
- Ciasny budżet hostingu: dobrze zrobiona strona SSG działa na darmowym planie Vercel/Cloudflare do kilku milionów wizyt.
