← Wszystkie posty7 min czytania

Post · 20

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

SSG: HTML generowany przy build, deploy na CDN. Najszybsze strony jakie da się zrobić. Next.js, Astro, Hugo, Jekyll. Kiedy używać, kiedy ISR, kiedy SSR.

  • SSG
  • performance
  • architektura

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.

FAQ

Najczęstsze pytania.

Czym SSG różni się od SSR?
SSG renderuje HTML raz przy build, deploy na CDN, każdy user dostaje ten sam plik. SSR renderuje per request na serwerze, każdy user może dostać inny content. SSG szybsze i tańsze, SSR daje dynamic content.
Czy SSG nadaje się do e-commerce?
Tak dla katalogu produktów (statyczne strony per produkt, regenerated z ISR przy update ceny). Koszyk i checkout client-side / SSR (per-user). Hybrid podejście jest standardem.
Jak długo trwa build SSG dla 1000 stron?
Next.js ~2-5 minut, Astro ~1-3 min, Hugo ~10-30 sekund. Dla 10k+ stron Hugo wygrywa (Go-based, najszybszy). Dla average projektów (do 500 podstron) wszystkie OK.
Czy mogę używać SSG z bazą danych?
Tak. Build script fetchuje dane z DB/CMS przy `next build`, generuje statyczne HTML. ISR pozwala regenerować pojedyncze strony bez full rebuild (po update content via webhook).
Jaki framework SSG wybrać 2026?
Next.js dla 80% projektów (universal, najpopularniejszy, ekosystem). Astro dla content-heavy bez aplikacyjnej dynamiki. Hugo dla bardzo dużych stron (10k+ podstron). Jekyll deprecated.

Powiązane usługi

Pogadajmy

Masz pytanie? Napisz.

Kontakt→