Static Site Generation: co to jest i kiedy ma sens

W klasycznym modelu Static Site Generation właściwa wersja strony powstaje podczas procesu budowania. System pobiera potrzebną treść i na jej podstawie generuje ostateczne pliki HTML. Dzieje się to, zanim przeglądarka konkretnego użytkownika poprosi o daną podstronę.

To właśnie odróżnia SSG od renderowania wykonywanego na każde żądanie. Jeżeli podstrona została wcześniej wygenerowana, nie trzeba tworzyć jej od nowa w momencie wejścia użytkownika. Przeglądarka otrzymuje gotowy dokument HTML przygotowany w procesie budowania.

W praktyce oznacza to rozdzielenie dwóch momentów. Najpierw powstaje wersja strony przeznaczona do publikacji, a dopiero później odwiedzający zaczynają z niej korzystać. Treść nie musi być przy tym wpisana ręcznie w plikach HTML. Źródłem mogą być dane, które generator pobiera podczas budowania i zamienia na statyczne podstrony.

Ten model dobrze pasuje do treści, które dla wszystkich odwiedzających mają wyglądać tak samo. Strona firmy z opisem usług, artykuł na blogu czy dokumentacja nie muszą zwykle tworzyć innej wersji tekstu przy każdym otwarciu. Jeśli zawartość zmienia się dopiero po publikacji nowej wersji, wcześniejsze wygenerowanie HTML jest naturalnym rozwiązaniem.

SSG nie oznacza natomiast, że cała strona musi być pozbawiona JavaScriptu albo jakiejkolwiek interakcji. Określenie dotyczy sposobu przygotowania dokumentu HTML. To, co dzieje się później w przeglądarce, zależy już od architektury konkretnego projektu.

Najłatwiej zrozumieć SSG, patrząc na proces budowania jako na etap produkcji gotowych podstron. Generator zna strukturę serwisu, pobiera potrzebne dane, łączy je z szablonami i przygotowuje pliki HTML, które można później opublikować.

Jeżeli serwis ma wiele podstron opartych na jednym schemacie, generator może utworzyć je na podstawie zestawu danych. Dobrym przykładem są artykuły blogowe, strony poszczególnych usług albo rozbudowana baza treści. Każdy adres może otrzymać osobny, wcześniej przygotowany dokument HTML.

W Next.js z katalogiem app dynamiczne trasy przeznaczone do statycznego wygenerowania mogą korzystać z funkcji generateStaticParams. Jej zadaniem jest wskazanie parametrów potrzebnych do przygotowania konkretnych adresów podczas procesu budowania. Dla właściciela strony najważniejszy jest efekt: podstrony znane przed publikacją mogą zostać utworzone wcześniej, zamiast powstawać dopiero przy wejściu odwiedzającego.

Next.js pozwala również przygotować projekt jako całkowicie statyczny eksport. Odpowiednie ustawienie w konfiguracji powoduje, że wynik może działać bez uruchomionego serwera Node.js odpowiedzialnego za generowanie stron. To rozwiązanie ma sens wtedy, gdy funkcje wymagające takiego serwera nie są potrzebne.

Sam proces budowania ma też konsekwencję organizacyjną. Zmiana danych użytych do wygenerowania strony nie zawsze oznacza natychmiastową zmianę gotowego HTML. Jeżeli projekt korzysta wyłącznie z klasycznego SSG, nowa treść musi znaleźć się w kolejnej wygenerowanej wersji. Właśnie ten problem częściowo rozwiązuje ISR.

Jeśli chcesz szerzej zobaczyć, gdzie statyczne generowanie mieści się w nowoczesnej architekturze stron, opisałem również Jamstack: co to jest. SSG jest jednym z ważnych mechanizmów w takim podejściu, ale nie oznacza, że każdy serwis musi działać wyłącznie statycznie.

Incremental Static Regeneration, czyli ISR, rozszerza model statycznego generowania. Zamiast przebudowywać cały serwis po każdej zmianie, można ponownie wygenerować konkretną stronę po określonym czasie wskazanym przez mechanizm revalidate.

Po ludzku oznacza to, że podstrona nadal może działać jak wcześniej przygotowany dokument, ale nie musi czekać na pełne ponowne zbudowanie całego serwisu, aby dostać nowszą wersję. Mechanizm może odświeżyć pojedynczy HTML w tle.

To przydatne w serwisach, w których treść jest zasadniczo publiczna i taka sama dla każdego odwiedzającego, lecz zmienia się częściej niż w typowej statycznej stronie firmowej. Zamiast wybierać wyłącznie między niezmiennym HTML a generowaniem wszystkiego przy każdym zapytaniu, można zastosować model pośredni.

ISR nie jest jednak synonimem danych aktualizowanych w każdej chwili. Jeżeli konkretna informacja musi odzwierciedlać zmianę natychmiast przy każdym wejściu, okresowe przebudowanie statycznej strony może nie odpowiadać wymaganiom projektu. Trzeba wtedy rozważyć mechanizm dynamiczny albo połączenie kilku sposobów renderowania.

SSR jest więc innym narzędziem do innego rodzaju problemu. Więcej o tym mechanizmie opisuję we wpisie Server-Side Rendering.

Najbardziej oczywistym zastosowaniem SSG są strony, których publiczna treść nie zmienia się w zależności od konkretnego użytkownika. Oferta firmy, opis usług, informacje o zespole czy dane publikowane w artykułach mogą zostać przygotowane wcześniej i udostępnione jako gotowe dokumenty HTML.

Podobnie działa wiele blogów. Artykuł ma określoną treść i po publikacji każdy czytelnik powinien zobaczyć tę samą wersję. Jeżeli pojawi się poprawka albo nowy wpis, można przygotować nową wersję statyczną. Przy częstszych zmianach można natomiast wykorzystać mechanizm odświeżania taki jak ISR.

Dokumentacja również dobrze wpisuje się w ten model. Jej struktura składa się zwykle ze znanych stron i sekcji, a treść zmienia się razem z kolejnymi aktualizacjami materiałów. Nie ma potrzeby generowania całego dokumentu od początku dla każdej osoby, która otworzy konkretny rozdział.

SSG nadaje się też do stron marketingowych, portfolio i landing page, o ile ich zawartość nie zależy od danych konkretnego użytkownika. W każdym z tych przypadków podstawowe pytanie jest podobne: czy można przygotować publiczną wersję podstrony przed wejściem odwiedzającego? Jeśli tak, statyczne generowanie jest rozwiązaniem, które warto brać pod uwagę.

Nie znaczy to, że cały rozbudowany serwis musi być statyczny. Nowoczesny projekt może łączyć różne sposoby renderowania zależnie od trasy i rodzaju danych. Publiczna część informacyjna może korzystać ze statycznego HTML, podczas gdy fragment wymagający danych przypisanych do użytkownika potrzebuje innego mechanizmu.

Takie podejście jest szczególnie istotne przy projektowaniu stron Jamstack, gdzie sposób pobierania danych, generowania widoków i publikowania treści dobiera się do charakteru konkretnego serwisu, a nie do jednej zasady stosowanej wszędzie.

Statyczne generowanie przestaje być naturalnym wyborem, gdy zawartość strony musi powstawać na podstawie danych dostępnych dopiero w momencie zapytania. Dotyczy to między innymi ekranów zależnych od zalogowanego użytkownika. Panel, w którym każda osoba ma zobaczyć własne dane, nie może bazować wyłącznie na jednym wcześniej wygenerowanym dokumencie wspólnym dla wszystkich.

Podobny problem pojawia się przy treściach, które zmieniają się bardzo często. Jeśli każda zmiana powinna być natychmiast widoczna dla kolejnej osoby odwiedzającej stronę, klasyczne SSG może wymagać zbyt częstego ponownego budowania. ISR pomaga wtedy, gdy akceptowalne jest odświeżanie konkretnej podstrony według ustalonych zasad, ale nie zastępuje wszystkich przypadków dynamicznych.

Osobną kategorią są formularze i procesy wymagające logiki wykonywanej po stronie serwera. Sam formularz może znajdować się na statycznie wygenerowanej stronie, lecz obsługa wysłanych danych może potrzebować osobnego zaplecza. SSG opisuje sposób tworzenia strony, a nie usuwa potrzeby serwera wszędzie tam, gdzie aplikacja faktycznie musi wykonać operację po stronie zaplecza.

Dlatego nie traktuję SSG jako zasady, którą trzeba narzucać całemu projektowi. Najpierw patrzę na rodzaj treści i funkcje. Publiczny opis usługi może być statyczny, a panel użytkownika dynamiczny. Katalog może korzystać z wcześniej przygotowanych stron, a elementy wymagające aktualnych danych mogą działać inaczej.

Granica jest dość praktyczna. Jeśli treść da się określić przed wejściem użytkownika, SSG pasuje do problemu. Jeśli odpowiedź zależy od tego, kto właśnie wszedł, co przed chwilą wydarzyło się w systemie albo jakie dane są dostępne dokładnie w momencie zapytania, potrzebny może być mechanizm dynamiczny.

SSG nie jest nazwą jednego frameworka. To sposób przygotowania stron, który występuje w różnych narzędziach. Do rozwiązań zorientowanych na generowanie statyczne należą Astro, Hugo i Eleventy. Next.js również obsługuje statyczne generowanie, ale pozwala łączyć je z innymi sposobami renderowania w ramach jednego projektu.

Wybór narzędzia powinien więc wynikać z architektury strony. Jeżeli serwis ma przede wszystkim publikować treść, generator statyczny może odpowiadać całemu projektowi. Jeśli obok statycznych podstron występują funkcje aplikacyjne, logowanie albo fragmenty wymagające renderowania po stronie serwera, przydatna staje się możliwość mieszania różnych modeli.

Next.js daje taką elastyczność na poziomie tras. Projekt może korzystać ze stron przygotowanych statycznie, odświeżanych przez ISR oraz elementów generowanych dynamicznie. Z kolei przy projekcie, który ma być w całości statyczny, można zastosować eksport bez uruchomionego serwera Node.js.

Astro jest przykładem narzędzia, którego używam przy serwisach statycznych budowanych z danych. Ten model pozwala wziąć jedną bazę treści i przygotować na jej podstawie wiele publicznych podstron. Mechanizm pozostaje ten sam: dane są znane podczas budowania, więc wynikowy HTML można wygenerować wcześniej.

Wśród narzędzi związanych historycznie ze statycznym generowaniem pojawia się również Gatsby. Po przejęciu przez Netlify w 2023 roku wygaszono Gatsby Cloud, a rozwój samego frameworka wyraźnie zwolnił. Dlatego przy nowym projekcie patrz nie tylko na to, czy narzędzie obsługuje SSG, ale też na jego aktualny sposób rozwoju.

Najważniejszy pozostaje jednak model danych i treści, a nie etykieta frameworka. SSG ma sens wtedy, gdy stronę można przygotować przed zapytaniem użytkownika. ISR rozszerza ten model o późniejsze odświeżanie wybranych podstron, a SSR pozwala generować HTML na serwerze w momencie wejścia. Dobór między nimi powinien wynikać z tego, kiedy dane są znane i jak szybko muszą znaleźć się w widoku użytkownika.