Headless WordPress, ISR czy SSR: tryb renderowania dobierany do rytmu zmian treści
Pytanie “ISR czy SSR” ma sens tylko w odniesieniu do konkretnej trasy. Nie ma jednej odpowiedzi dla całego serwisu. Astro i Next.js pozwalają wybrać tryb na poziomie strony albo layoutu, a dojrzałe podejście inżynierskie polega na świadomym wyborze, trasa po trasie, w oparciu o model tego, jak często zmienia się treść.
Ten artykuł należy do filaru usługi headless WordPress i uzupełnia macierz decyzyjną Next.js czy Astro, która opisuje wybór na poziomie frameworka.
W skrócie
- ISR (albo strona statyczna z rewalidacją) wygrywa, gdy rytm zmian treści jest przewidywalny, a ruch duży.
- SSR wygrywa, gdy strona jest personalizowana, zależy od sesji albo zawiera dane na żywo.
- O poprawności ISR decyduje unieważnianie cache; webhooki są lepsze niż rewalidacja czasowa.
- Cloudflare Workers obsługuje oba tryby; ISR nie zużywa prawie wcale CPU, SSR płaci za pełne renderowanie.
- Punktem wyjścia jest najtańszy tryb, który zapewnia poprawność; na SSR przechodzisz tylko wtedy, gdy to konieczne.
SSG, ISR i SSR w kontekście WordPressa
Statyczne generowanie stron (SSG). Strona powstaje raz, podczas builda, i jest serwowana jako zwykły HTML. Najtańsza w momencie żądania, najwolniejsza w aktualizacji.
Incremental Static Regeneration (ISR). Strona powstaje raz, ale można ją wygenerować ponownie po wyzwalaczu, zwykle webhooku przy publikacji albo po upływie interwału rewalidacji. Tania w momencie żądania, aktualizacja z ostateczną spójnością.
Server-Side Rendering (SSR). Strona jest renderowana przy każdym żądaniu. Zawsze świeża, ale koszt działania rośnie razem z ruchem. Personalizacja, uwierzytelnianie i dane na żywo pasują tu naturalnie.
W headless WordPress wszystkie trzy tryby czytają dane z originu WordPressa przez REST albo GraphQL. Różnią się tym, kiedy to robią.
Kiedy ISR, a kiedy SSR w headless WordPress
Liczą się dwa czynniki:
Rytm zmian treści. Jak często ta strona się zmienia? Raz na kwartał, raz dziennie, co minutę, w czasie rzeczywistym?
Zakres personalizacji. Czy strona różni się w zależności od odwiedzającego? Stan zalogowania, ceny zależne od lokalizacji, wariant testu A/B.
Reguła: wybierz najtańszy tryb, który zapewnia poprawność. Statyczny jest najtańszy. SSR najdroższy. Przesuwaj się w stronę SSR tylko wtedy, gdy tańszy tryb nie daje poprawnego wyniku.
| Typ strony | Tryb domyślny | Dlaczego |
|---|---|---|
| Strony marketingowe, wpisy na blogu | Statyczny (przebudowa przy publikacji) | Rzadkie zmiany, brak personalizacji |
| Archiwa kategorii i tagów | ISR z webhookiem publikacji | Rytm zależy od publikacji treści |
| Strony produktów, stabilny katalog | ISR z webhookiem stanów magazynowych | Przewidywalne unieważnianie |
| Strony produktów, stany w czasie rzeczywistym | SSR z cache na brzegu | Stany zmieniają się w ciągu sekund |
| Koszyk i checkout | SSR | Z definicji zależą od sesji |
| Panel po zalogowaniu | SSR | Stan per użytkownik |
| Redakcyjna strona główna | ISR z webhookiem publikacji | Rytm zależy od zdarzeń publikacji |
Unieważnianie cache ISR webhookami z WordPressa
ISR wydaje się darmowe, dopóki po zmianie sluga nie zacznie serwować nieaktualnego adresu kanonicznego. Wzorzec, który temu zapobiega:
Unieważnianie sterowane webhookami. WordPress wysyła webhook przy publikacji, zmianie sluga albo usunięciu wpisu. Framework frontendowy odbiera webhook i uruchamia regenerację stron, których zmiana dotyczy. Koszt to jedna integracja webhooka po stronie originu WordPressa, ponoszony raz.
Rewalidacja czasowa wyłącznie jako zabezpieczenie. Interwał rewalidacji 60 sekund pokrywa przypadki, gdy webhook nie dotrze, ale nie powinien być głównym wyzwalaczem. Strona rewalidowana co 60 sekund jest też przebudowywana 60 razy na godzinę; przy serwisie z 5000 stron tego nie da się utrzymać.
Tagi cache zamiast adresów URL. Każda strona w cache dostaje tag z ID wpisu w WordPressie, ID terminów taksonomii, do których się odwołuje, oraz tagi przekrojowe (strona główna, sitemap). Gdy przychodzi webhook, front czyści cache po tagu, a nie po adresie. To różnica między “wygeneruj ponownie stronę produktu” (kruche) a “wygeneruj ponownie wszystko, co odwołuje się do produktu 8421” (poprawne).
Koszt ISR i SSR na Cloudflare Workers
Astro i Next.js kompilują się do środowiska zgodnego z Workers. Koszty w podziale na tryby:
- Statyczne strony na brzegu. Cloudflare Pages serwuje zwykły HTML przy prawie zerowym zużyciu CPU na żądanie. Najtańszy tryb.
- ISR. Pierwsze żądanie po unieważnieniu płaci pełny koszt renderowania; żądania z cache prawie nic. Workers obsługuje oba przypadki.
- SSR. Każde żądanie płaci na Workers pełny koszt renderowania. Przewidywalnie per żądanie, drogo przy dużej skali.
Różnica kosztów ma znaczenie przy dużym ruchu. Przy małym ruchu o wyborze decyduje poprawność, nie koszt.
Przykłady ISR i SSR dla prawdziwych tras WordPressa
Marketingowa strona główna. Statyczna, przebudowywana webhookiem przy każdej publikacji redakcyjnej. Cache na brzegu przez 24 godziny z możliwością ręcznego wyczyszczenia. SSR jako wyjście awaryjne tylko wtedy, gdy dojdzie baner zależny od kraju.
Karta produktu w WooCommerce. ISR z kluczem w postaci ID produktu. Webhook z WooCommerce przy zmianie stanu, ceny albo treści. Okno cache: 1 godzina jako zabezpieczenie. SSR tylko wtedy, gdy wyświetlanie stanów w czasie rzeczywistym jest wymogiem UX.
Historia zamówień klienta. SSR. Dane per użytkownik, zależne od sesji, bez cache na brzegu.
Ta sama architektura, trzy różne tryby renderowania, jedna reguła decyzyjna.
Powiązane poradniki o headless WordPress
Ten artykuł należy do filaru usługi headless WordPress. Wybór na poziomie frameworka opisuje macierz decyzyjna Next.js czy Astro.
Wdrożeniową stronę tego tematu prowadzimy w ramach usługi audyt Core Web Vitals.
