Jak zmiana w Storybloku trafia na stronę - webhook, build, CDN

Klikasz Publish w Storybloku i w 30-90 sekund zmiana jest na żywo - ten artykuł rozkłada ten proces na czynniki pierwsze.

Trzy etapy: webhook, build, deploy

Cały pipeline działa w trzech krokach, każdy wyzwalany przez poprzedni.

Etap 1: Webhook

Każde kliknięcie Publish w Storybloku wysyła żądanie HTTP POST na skonfigurowany adres webhook. Ten adres należy do platformy hostingowej - Vercel, Netlify, Cloudflare Pages.

W żądaniu webhook jest minimalna informacja: zdarzenie (story_published), identyfikator historii i przestrzeni. Platforma hostingowa nie potrzebuje więcej - jej jedynym zadaniem jest odebranie sygnału i uruchomienie buildu.

Czas od kliknięcia Publish do wysłania webhook: poniżej 1 sekundy.

Etap 2: Build Astro

Platforma hostingowa uruchamia build Astro. W tym kroku:

1. Pobiera kod frontendu z repozytorium GitHub

2. Instaluje zależności npm

3. Uruchamia `astro build`

4. Astro odpytuje Storyblok API po aktualną treść wszystkich stron

5. Generuje statyczny HTML dla każdej podstrony

6. Optymalizuje obrazy, minifikuje CSS i JavaScript

Czas buildu przy typowej stronie firmowej (20–40 podstron): 30-90 sekund. Przy większych serwisach z setkami stron - 2–5 minut.

To kluczowa różnica względem WordPressa: WordPress składa HTML przy każdym wejściu użytkownika. Astro składa HTML raz, po opublikowaniu treści. Każdy kolejny użytkownik dostaje gotowy plik — bez zapytań do bazy danych, bez renderowania PHP.

Etap 3: Deploy na CDN

Gotowe pliki statyczne trafiają na CDN (Content Delivery Network). Vercel ma punkty obecności w kilkudziesięciu lokalizacjach na świecie - w Europie, Azji, Ameryce.

Przy nowym deployu stary cache jest unieważniany. Użytkownik następny otwierający twoją stronę dostaje pliki z najbliższego węzła CDN — zazwyczaj w odległości kilkuset kilometrów, czas transferu poniżej 50 ms.

Czas od końca buildu do aktywacji nowej wersji: poniżej 10 sekund.

Diagram całego pipeline'u

Storyblok (klik Publish)
    ↓ HTTP POST webhook (~1 s)
Vercel / Netlify / Cloudflare Pages
    ↓ git pull + npm install + astro build (~30–90 s)
    Astro odpytuje Storyblok API → generuje HTML
    ↓ upload plików statycznych (~5–10 s)
CDN (edge nodes na całym świecie)
    ↓ cache unieważniony
Użytkownik dostaje nową wersję

Łączny czas od Publish do live: 30–90 sekund przy typowej konfiguracji.

Dlaczego Astro pobiera treść przy buildzie, a nie przy wejściu użytkownika

To fundamentalne pytanie dla zrozumienia architektury. W klasycznym podejściu (WordPress, PHP) serwer odpytuje bazę danych przy każdym wejściu użytkownika i składa stronę dynamicznie. Każde zapytanie kosztuje czas — stąd 500–2000 ms Time to First Byte.

W Astro treść z CMS jest "wbudowana" w HTML podczas buildu. Storyblok API jest odpytywane raz, a nie milion razy dziennie. Użytkownik dostaje gotowy HTML z CDN - serwer nie robi w tym momencie nic.

Co dzieje się przy awarii buildu

Jeśli build się nie powiedzie (błąd składni w Storyblok, niedostępne API, problem z kodem), platforma hostingowa:

• Nie deployuje nowej wersji

• Pozostawia poprzednią wersję aktywną

• Informuje o błędzie przez e-mail lub webhook powiadomień

Stara strona działa bez przerwy. Użytkownik nic nie widzi. Build error jest widoczny tylko w dashboardzie platformy.

To ważna cecha odróżniająca ten stack od WordPressa: błąd przy publikacji nie może "wysypać" działającej strony — bo strona statyczna nie zależy od procesu publikacji.

Zaplanowane publikacje i harmonogram

Storyblok obsługuje harmonogram publikacji - możesz ustawić datę i godzinę, kiedy wpis ma się pojawić. Storyblok wysyła webhook o ustalonej godzinie, a cały pipeline uruchamia się identycznie jak przy ręcznym Publish.

Wersjonowanie i rollback

Każdy deploy na Vercel lub Cloudflare Pages tworzy nowy snapshot. Jeśli po publikacji coś wygląda źle, rollback do poprzedniej wersji to jedno kliknięcie w dashboardzie platformy - bez ingerencji w Storybloka, bez kontaktu z agencją.