Czy Astro zastępuje React?

Nie. Astro renderuje komponenty React, Vue, Svelte czy Preact do HTML-u w czasie budowania, a do przeglądarki wysyła ich kod tylko wtedy, gdy oznaczysz je dyrektywą client. React zostaje w projekcie tam, gdzie potrzebna jest interaktywność — zmienia się zakres jego użycia, nie sam framework.

Ile JavaScriptu wysyła strona zbudowana w Astro?

Strona bez ani jednej wyspy wysyła zero JavaScriptu aplikacyjnego. Każda wyspa dokłada wyłącznie własny pakiet, ładowany zgodnie z użytą dyrektywą. Realna waga zależy więc od liczby interaktywnych komponentów i bibliotek, których używają, a nie od rozmiaru całego projektu.

Czy strona w Astro może mieć formularz kontaktowy i logowanie?

Tak. Formularz można obsłużyć endpointem po stronie serwera lub funkcją hostingu, a widoki zależne od sesji renderować przez tryb serwerowy albo server islands wprowadzone w Astro 5. Reszta strony pozostaje statyczna i dalej idzie prosto z CDN.

Czym Astro różni się od zwykłego generatora stron statycznych?

Klasyczny generator produkuje HTML i kończy pracę — interaktywność trzeba dopisać samodzielnie. Astro dokłada model wysp: komponenty z popularnych frameworków renderują się do HTML-u, a ich hydratacja jest sterowana per komponent, wraz z momentem załadowania kodu.

Czy Astro sprawdzi się przy serwisie z tysiącami podstron?

Tak, choć wtedy istotny staje się czas budowania. Content layer w Astro 5 przyspiesza budowanie kolekcji treści do pięciu razy dla Markdowna i do dwóch razy dla MDX. Przy bardzo dużych i często zmienianych katalogach rozważa się dodatkowo renderowanie części tras na żądanie.

Astro i architektura wysp — jak to działa

Jak Astro renderuje stronę do statycznego HTML-u, czym sterują dyrektywy client, dlaczego architektura wysp poprawia Core Web Vitals i kiedy przestaje się opłacać.

Astro domyślnie nie wysyła do przeglądarki ani jednego kilobajta JavaScriptu aplikacyjnego — strona trafia do użytkownika jako gotowy HTML, a kod otrzymują wyłącznie te fragmenty, które faktycznie muszą reagować na kliknięcia. Ten wzorzec nazywa się architekturą wysp (islands architecture) i odpowiada za większość przewagi wydajnościowej Astro nad klasyczną aplikacją jednostronicową.

Poniżej rozkładamy mechanizm na części: co dzieje się w trakcie budowania strony, czym sterują dyrektywy client:*, jak to przekłada się na Core Web Vitals i gdzie ta architektura przestaje się opłacać.

Czym jest architektura wysp

Architektura wysp to wzorzec, w którym cała strona jest statycznym HTML-em, a interaktywność dostają tylko wydzielone komponenty — każdy hydratowany osobno, własnym, małym pakietem JavaScriptu.

W aplikacji jednostronicowej (SPA) zbudowanej w React czy Vue kolejność jest odwrotna: przeglądarka najpierw pobiera i wykonuje pakiet całej aplikacji, a dopiero potem strona staje się klikalna. Do tego momentu użytkownik widzi treść, która wygląda na gotową, ale nie reaguje na dotyk.

Astro odwraca ten porządek. Treść jest kompletna od pierwszego bajtu HTML-u, a interaktywność dochodzi punktowo — wyspa po wyspie. Strona bez ani jednej wyspy wysyła zero JavaScriptu aplikacyjnego. Strona z jednym kalkulatorem wysyła tyle, ile waży ten kalkulator, a nie cały framework z całym drzewem komponentów (dokumentacja Astro: Islands architecture).

Co dzieje się podczas budowania strony

Astro renderuje komponenty do czystego HTML-u — w czasie builda na maszynie CI, nie w przeglądarce użytkownika.
Kod JavaScript tych komponentów jest usuwany, o ile komponent nie został jawnie oznaczony dyrektywą client:*.
Każda wyspa dostaje własny pakiet. Nie ma jednego wspólnego bundla, który musiałby się załadować w całości, zanim cokolwiek zacznie działać.
Style są zbierane i wstrzykiwane per strona, a nie jako jeden arkusz obsługujący całą witrynę.
Obrazy przechodzą przez astro:assets (domyślnie biblioteka sharp): konwersja do formatów WebP i AVIF, skalowanie oraz atrybuty width i height wyliczone z pliku źródłowego.

Ostatni punkt jest ważniejszy, niż wygląda. Wpisany z góry rozmiar obrazu rezerwuje miejsce w layoucie, więc tekst nie przeskakuje w trakcie ładowania — to bezpośrednio pilnuje metryki CLS. Komponent Image ustawia też domyślnie loading="lazy" i decoding="async", więc grafika spoza pierwszego ekranu nie konkuruje o pasmo z treścią, którą użytkownik właśnie czyta (dokumentacja Astro: Images).

Dyrektywy client — czym dokładnie sterują

Dyrektywa client:* to jedyne miejsce, w którym deweloper decyduje o wysłaniu JavaScriptu do przeglądarki. Brak dyrektywy oznacza brak kodu klienckiego dla tego komponentu.

Dyrektywa	Kiedy ładuje się JavaScript	Typowe zastosowanie
`client:load`	natychmiast po wczytaniu strony	element nad linią zgięcia, z którego korzysta prawie każdy użytkownik
`client:idle`	gdy przeglądarka przestanie mieć pilniejszą pracę	elementy potrzebne, ale nie w pierwszej sekundzie — np. zapis do newslettera
`client:visible`	gdy komponent wejdzie w pole widzenia	wszystko poniżej pierwszego ekranu: kalkulatory, mapy, karuzele, akordeony
`client:media`	gdy pasuje podane zapytanie media	menu mobilne, komponenty istotne tylko na jednym typie ekranu
`client:only`	pomija render na serwerze, działa wyłącznie w przeglądarce	komponenty zależne od `window` lub pamięci przeglądarki

Reguła, którą stosujemy w projektach: domyślnie client:visible, client:load tylko dla interakcji dostępnych bez przewijania. Zamiana jednej dyrektywy na drugą nie zmienia kodu komponentu — zmienia moment, w którym jego pakiet w ogóle trafia do sieci.

Dlaczego to widać w Core Web Vitals

Core Web Vitals to trzy metryki, którymi Google mierzy rzeczywiste doświadczenie użytkownika, oceniane na 75. percentylu ruchu: LCP (czas wyrenderowania największego widocznego elementu, próg „dobry" to maksymalnie 2,5 s), INP (czas odpowiedzi na interakcję, maksymalnie 200 ms) i CLS (stabilność layoutu, maksymalnie 0,1) — web.dev/articles/vitals.

Architektura wysp działa na każdą z tych trzech metryk osobno. LCP: największy element to zwykle nagłówek lub obraz z pierwszego ekranu, a ten jest już w HTML-u — nie czeka na wykonanie JavaScriptu. INP i powiązany z nim TBT: wątek główny nie jest zajęty parsowaniem i wykonywaniem pakietu aplikacji, więc pierwsze kliknięcie ma wolny procesor. CLS: rozmiary obrazów i brak komponentów doklejanych po hydratacji oznaczają, że layout nie przesuwa się po wyrenderowaniu.

To nie jest gwarancja dobrego wyniku, tylko usunięcie najczęstszej przyczyny złego. Ciężka wyspa z client:load, zewnętrzny skrypt czatu albo trzy narzędzia analityczne potrafią zniwelować całą przewagę — o tym, jak to kontrolujemy, piszemy w artykule o wpływie wydajności na konwersję. Jak wygląda odczyt strony zbudowanej w tym modelu, pokazujemy na wynikach PageSpeed Insights dla aiact.waw.pl.

Astro 5: server islands i content layer

Astro 5, wydane 3 grudnia 2024, dołożyło do tego modelu dwie rzeczy istotne przy stronach firmowych i produktowych.

Server islands pozwalają odroczyć renderowanie dynamicznego fragmentu do momentu po dostarczeniu strony. Statyczny HTML idzie z CDN natychmiast, a panel użytkownika, licznik czy sekcja personalizowana dorenderowuje się po stronie serwera bez zamieniania całej strony w dynamiczną.

Content layer to jednolite, typowane API do wczytywania treści — z plików, z API albo z bazy. Zespół Astro podaje przy tej zmianie przyspieszenie budowania kolekcji treści do pięciu razy dla plików Markdown i do dwóch razy dla MDX oraz spadek zużycia pamięci o 25–50% (astro.build/blog/astro-5).

Kiedy architektura wysp się nie opłaca

Astro jest optymalne dla stron, gdzie treść jest głównym produktem, a interaktywność jest wyspowa: strony firmowe, landing page, dokumentacja, blogi, katalogi, kalkulatory i formularze.

Przestaje być optymalne tam, gdzie interfejs sam jest aplikacją: panel administracyjny ze stanem współdzielonym przez wszystkie widoki, edytor dokumentów, narzędzie czasu rzeczywistego, ekran z ciągłą synchronizacją danych. Tam pełna aplikacja React czy Next.js jest właściwym narzędziem — rozstrzygamy to w porównaniu Astro, WordPressa i Next.js.

Checklista: czy Twój projekt nadaje się na Astro

Policz strony, których treść zmienia się rzadziej niż raz dziennie — im więcej, tym lepiej.
Wypisz elementy naprawdę interaktywne: formularz, kalkulator, filtr, mapa, akordeon.
Sprawdź, czy te elementy działają niezależnie od siebie, czy dzielą wspólny stan.
Zweryfikuj, czy potrzebujesz logowania i widoków per użytkownik na każdej podstronie.
Zbierz listę zewnętrznych skryptów (analityka, czat, piksele) i ich realny koszt w kilobajtach.
Ustal, kto i jak często będzie edytować treść — to decyduje o wyborze źródła treści.
Zmierz obecne Core Web Vitals, żeby po wdrożeniu mieć punkt odniesienia, a nie wrażenie.

Najczęstsze błędy przy pracy z wyspami

Dyrektywa client:load na wszystkim. Efekt: pakiet ładuje się dla komponentów, których użytkownik nigdy nie zobaczy. Naprawa: domyślnie client:visible, wyjątki uzasadnione pozycją na stronie.
Ciężka biblioteka w małej wyspie. Formatowanie daty albo pojedyncza funkcja pomocnicza potrafi przynieść kilkadziesiąt kilobajtów zależności. Naprawa: import punktowy albo natywne API przeglądarki.
Zdalne obrazy bez wymiarów. Astro wylicza wymiary tylko dla plików lokalnych — przy obrazach z zewnętrznego źródła trzeba podać je ręcznie, inaczej rośnie CLS.
Skrypty zewnętrzne dokładane „na koniec". Widżety czatu, testy A/B i piksele reklamowe wracają na wątek główny i psują INP. Każdy taki skrypt traktujemy jak decyzję kosztową, nie jak detal wdrożeniowy.

Ten sam sposób myślenia — pełna kontrola nad tym, co i kiedy trafia do przeglądarki — stosujemy w projektach e-commerce, które opisujemy w artykule o architekturze headless Shopify.