Static Site Generation
Tym razem przyjrzymy się renderowaniu z nieco innej perspektywy. A co jeśli można by było zbudować całą stronę, zanim ktokolwiek o to poprosi? Właśnie tym zajmie się bohater dzisiejszego wpisu.
Szczęście sprzyja przygotowanym
Posługując się metaforą, Static Site Generation to taki świetnie przygotowany gość, który ma już gotową odpowiedź, zanim ktokolwiek zdąży zadać pytanie.
To podejście realizuje strategię, którą możemy streścić następująco:
"Zamiast reagować na liczne zapytania użytkowników i w pośpiechu generować dla nich treść może warto rozpocząć cały proces, zanim jakiekolwiek zapytanie przyjdzie do serwera"?
Na pierwszy rzut oka może brzmieć to dość magicznie, ale w wielu przypadkach jest możliwe. Weźmy pod uwagę witryny, których głównym zadaniem jest wyświetlanie dużej ilości statycznej treści, grafik itp.
Dlaczego mielibyśmy czekać na requesty od użytkowników skoro i tak wiemy, co chcemy im wyświetlić?
Proces krok po kroku
Dzisiaj nieco inaczej podejdziemy do tematu. Poprzednie strategie renderowania były liniowe, gdyż punktem wejścia było zapytanie użytkownika. SSG działa na długo przed pierwszym requestem.
Całość warto podzielić na dwie sekcje:
- Build Time
- Runtime
Build Time
- Serwer pobiera całą potrzebną treść, czyli tekst obrazki, video itp.
- Cała struktura strony jest budowana. Często serwer korzysta z różnych template engines. Są to narzędzia służące do generowania HTML'a na podstawie szablonów równocześnie wstawiając do nich dynamiczne dane, przykładowo Pug.js
Runtime
- Zbudowana witryna jest hostowana na serwerach CDN (Content Delivery Network). Istotne jest to, że całość jest statyczna i nie ma uruchomionego serwera w Runtime
- Użytkownik, wysyłając request bardzo szybko otrzymuje gotową stronę
Poniższa grafika powinna lepiej zobrazować cały proces:
Wady i Zalety
To podejście do renderowania wygląda ciekawie i zupełnie inaczej niż to, co oferują Client Side Rendering czy Server Side Rendering. Przeanalizujmy teraz ten model pod kątem wad i zalet:
Zalety:
- Świetna wydajność w Runtime. Użytkownik nie musi długo czekać na otrzymanie w pełni gotowej strony
- Wysoki poziom bezpieczeństwa. Brak serwera w czasie działania (Runtime) ogranicza możliwość ataków.
- Doskonałe SEO. Roboty indexujące bardzo sprawnie analizują tego typu witryny.
- Niskie koszty utrzymania serwera. Hosting statycznych plików jest jednym z najtańszych
Wady:
- Cały proces budowania i deploymentu na CDN może być dość długi, zwłaszcza jeśli nasza strona jest bardzo rozbudowana i zawiera mnóstwo treści
- Problematyczne debugowanie i wykrywanie błędów. Skoro nie ma serwera w Runtime ciężko śledzić zapytania i uzyskać jakieś logi
- Wszystkie dane muszą być znane w momencie budowania. Wprowadzenie dynamicznej treści wymaga przebudowania całej aplikacji
Incremental Static Regeneration
Największą z wad SSG jest zdecydowanie brak możliwości wprowadzania dynamicznej treści po odbytym procesie budowania. Napływające dynamicznie dane wymagają przebudowania całej aplikacji i ponownego deploymentu. Jest to zwłaszcza problematyczne, jeśli wprowadzamy jakiekolwiek, nawet mało istotne, ale jednak dość regularne zmiany.
Odpowiedzią na te ograniczenia jest Incremental Static Regeneration
ISR działa na dwóch płaszczyznach:
- dodawanie nowych ścieżek
- Aktualizacja treści na już istniejących routach
Pozostając w kontekście Next.js obsługę nowych stron dodajemy za pomocą parametru fallback w funkcji getStaticPaths. Określa on, jak ma zachować się aplikacja, gdy użytkownik zażąda podstrony, która jeszcze nie jest zbudowana.
Sprawi to, że w momencie zarequestowania nowej, niezbudowanej do tej pory strony serwer rozpocznie proces jej generowania. W wyniku tego pierwszy użytkownik doświadczy opóźnionego dostarczenia treści, ale już każdy kolejny otrzyma nową stronę bardzo szybko.
Aktualizację treści na istniejących podstronach jesteśmy w stanie zrealizować interwałowo. Za pomocą atrybutu revalidate wewnątrz funkcji getStaticProps z wartością ustawioną na konkretną liczbę sekund sprawimy, że serwer co jakiś czas sam z siebie przebuduje strony, dostarczając nową treść.
Instrukcję użycia powyższego API znajdziesz tutaj
Zastosowanie
W tym przypadku również warto skorzystać z gotowych frameworków. Samodzielna konfiguracja oczywiście jest możliwa, ale raczej mocno opóźni start developmentu. Będzie także skomplikowana i niekoniecznie tak wydajna, jak przetestowane w boju rozwiązania.
Next.js oferuje nam gotowe API, do obsługi tego typu aplikacji Na rynku są również rozwiązania takie jak Gatsby, Hugo, Remix itp.
https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation
https://remix-ssg.pages.dev/ https://gohugo.io/ https://www.gatsbyjs.com/docs/glossary/static-site-generator/
Gdzie wykorzystać wyżej wymienione frameworki? Dobrym use casem są wszelkiego rodzaju strony typu Landing Page, które mają za zadanie wyświetlić statyczną treść i dobrze się pozycjonować.
SSG sprawdzi się również w kontekście blogów (ale tutaj w wariancie z ISR) i różnego rodzaju stron wizytówek dla firm czy personalnych portfolio.
Raczej nie ma sensu stosować tej technologii w aplikacjach użytku wewnętrznego czy mocno interaktywnych serwisach, bo ograniczenia dynamicznej treści prędzej czy później nas dogonią.
Podsumowanie
W dzisiejszym materiale rzuciliśmy nieco światła na zupełnie odmienne podejście do renderowania niż te, które opisaliśmy ostatnio. Z pewnością w wielu sytuacjach będzie to najlepszy wybór i wyniesie Twoje projekty na jeszcze wyższy poziom.