Architektura wysp to wzorzec, w którym większość strony jest statycznym HTML-em, a interaktywne fragmenty hydratują się jako niezależne wyspy. nie jest kolejnym hasłem z marketingowej strony frameworka. To konkretny wzorzec, który zmienia sposób ładowania i uruchamiania strony w przeglądarce. Astro zbudowało wokół niego swoją przewagę, bo to właśnie dzięki temu strona w Astro może domyślnie ładować się bardzo szybko.
W tym artykule wyjaśniam, czym realnie są wyspy, jak działa selektywna hydracja i — co ważniejsze — kiedy ten wzorzec daje wymierną przewagę, a kiedy to tylko marketing.
Skąd się wziął termin „Islands Architecture"
Pojęcie zostało ukute w 2019 roku przez Katie Sylor-Miller, frontend architekta Etsy, a później rozwinięte przez Jasona Millera (twórcę Preacta) w jego poście z 2020 roku. Idea jest pozornie prosta: renderuj stronę jako HTML na serwerze, a w obszarach, które faktycznie potrzebują interaktywności, umieść niezależne, samodzielne komponenty, które hydratują się osobno.
W tradycyjnym podejściu SPA (React, Vue, Angular, Svelte bez SvelteKit) cała aplikacja jest jedną dużą wyspą interaktywności. Przeglądarka dostaje pusty HTML albo HTML wyrenderowany na serwerze, potem pobiera paczkę JavaScriptu, uruchamia framework, odtwarza drzewo komponentów i dopiero wtedy strona zaczyna reagować na kliknięcia. Użytkownik odczuwa to jako sytuację: „strona już się pokazała, ale jeszcze nie działa”.
Islands Architecture odwraca ten model. Strona jest domyślnie statycznym HTML-em, a interaktywność to wyjątek, który aktywnie deklarujesz.
Jak to działa w Astro
Weźmy typową stronę firmową: nagłówek z logo, hero, sekcję usług, formularz kontaktowy i stopkę. W tradycyjnym React/Next wszystkie te elementy są częścią aplikacji React, więc całe drzewo musi zostać zhydratowane, nawet jeśli interaktywny jest tylko formularz.
W Astro piszesz to tak:
Header, Hero, Services i Footer to komponenty .astro — renderują się na serwerze do czystego HTML-u i nie wysyłają do przeglądarki żadnego JavaScriptu związanego z tymi sekcjami. ContactForm to komponent React z dyrektywą client:visible; jego kod zostanie pobrany i uruchomiony dopiero wtedy, gdy użytkownik przewinie stronę do formularza.
Efekt: przeglądarka dostaje HTML, renderuje go natychmiast, użytkownik widzi treść i może przeglądać stronę w ułamku sekundy. JavaScript ładuje się w tle, selektywnie, tylko tam, gdzie jest potrzebny.
Zero JS domyślnie — co to naprawdę znaczy
W Next.js nawet strona, która wyświetla tylko statyczny tekst, ładuje runtime Reacta — reconciler, router, mechanizm hydracji. To 80–150 KB gzipped, zanim jakikolwiek Twój kod się wykonał. W Astro strona bez interaktywnych komponentów to dosłownie 0 KB JavaScriptu.
Żadnych skryptów UI. Żadnego startu frameworka. Żadnej hydracji komponentów. Przeglądarka pobiera HTML, parsuje CSS i pokazuje stronę.
Dla Lighthouse często oznacza to wynik Performance 95-100 bez ciężkiej optymalizacji. Dla Core Web Vitals: bardzo niski koszt JavaScriptu, dobry punkt wyjścia pod FCP i TBT oraz mniej ryzyka po stronie INP. Dla SEO: Google widzi treść od razu, bez czekania na renderowanie po stronie klienta.
Dyrektywy hydracji — kontrakt na wydajność
Kiedy już jakiś komponent musi być interaktywny, Astro daje Ci precyzyjną kontrolę nad tym, kiedy dostanie swój JavaScript. Pięć dyrektyw, pięć różnych strategii:
client:load— hydracja natychmiast po załadowaniu strony. Dla rzeczy krytycznych, ponad zagięciem.client:idle— hydracja, kiedy przeglądarka jest bezczynna (requestIdleCallback). Dla elementów ważnych, ale nie pilnych.client:visible— hydracja, kiedy komponent pojawia się w widocznym obszarze ekranu (IntersectionObserver). Dla elementów poniżej pierwszego ekranu.client:media="{query}"— hydracja tylko wtedy, gdy zapytanie media query pasuje. Dla UI przeznaczonego wyłącznie na mobile albo desktop.client:only="{framework}"— komponent renderuje się tylko po stronie klienta, pomijając SSR. Dla rzeczy zależnych od przeglądarki (np.window,localStorage).
Szczegółowo rozbieram każdą z nich w artykule o client directives w Astro.
Komponenty z różnych frameworków na jednej stronie
Architektura wysp ma jeszcze jedną konsekwencję, która w praktyce okazuje się bardziej użyteczna, niż się wydaje na pierwszy rzut oka — każda wyspa jest niezależna, więc może być napisana w innym frameworku.
W tradycyjnej SPA takie połączenie byłoby trudne do utrzymania, bo framework jest zwykle jeden. W Astro każda wyspa ładuje tylko runtime swojego frameworka i żyje we własnej paczce kodu.
Kiedy to się przydaje? Gdy masz komponent z zewnętrznej biblioteki napisany w Svelte i nie chcesz przepisywać go na React. Gdy migrujesz projekt z Vue na React etapami. Gdy używasz gotowego widgetu z biblioteki headless UI w innej technologii. Albo gdy budujesz wspólny system komponentów dla kilku projektów opartych na różnych stosach technologicznych.
Server Islands — dynamika w statycznej stronie
Kolejna ewolucja wzorca, dodana w Astro 5 i ustabilizowana w 6, to Server Islands. Działają odwrotnie niż klienckie wyspy: komponent nie renderuje się razem z główną stroną, tylko jego rendering jest odłożony i wykonywany po wysłaniu pierwszej odpowiedzi.
Użytkownik od razu dostaje statyczną stronę produktu z cache, a dynamiczny fragment, np. stan magazynu, rekomendacje albo koszyk, dociera osobnym żądaniem i wypełnia miejsce zastępcze, gdy jest gotowy. To łączy wydajność SSG z dynamiką SSR bez hydratowania komponentu frameworka po stronie klienta. Astro nadal wstawia mały skrypt techniczny, który pobiera zawartość wyspy serwerowej.
Szerzej opisuję ten mechanizm w artykule o Server Islands w Astro.
Kiedy Islands Architecture realnie wygrywa
Spójrzmy uczciwie — Astro nie jest magicznym rozwiązaniem na wszystko. Architektura wysp daje przewagę, gdy spełnione są konkretne warunki:
- Strona jest głównie treścią. Blog, dokumentacja, strona firmowa, portfolio, landing page, sklep z prostym koszykiem. Tam, gdzie większość powierzchni to tekst, obrazy i linki, a interaktywność pojawia się tylko w kilku miejscach.
- Core Web Vitals są krytyczne. Jeśli walczysz o pozycje w Google, konwersję z mobile albo wydajność na słabszym sprzęcie, eliminacja runtime'u frameworka to realna wygrana.
- Masz kontrolę nad tym, co interaktywne. Kiedy sam decydujesz, co potrzebuje JS, a co nie, możesz wyciągnąć maksimum z architektury wysp.
Kiedy Islands Architecture nie pomaga
I druga strona medalu:
- Aplikacja jest interaktywna w 80%+. Dashboard, panel admina, edytor, CRM, kalkulator finansowy z wieloma polami — tam, gdzie cała strona to interakcja, architektura wysp nie daje wiele. Wyspa to cała strona.
- Stan globalny jest konieczny. Jeśli wiele komponentów musi dzielić stan, np. koszyk, użytkownika albo preferencje UI, wyspy komplikują sprawę. Każda ma swój kontekst, a synchronizacja wymaga zewnętrznego magazynu stanu.
- Potrzebujesz frameworka fullstackowego. API Routes, Server Actions, middleware, auth, websockety — w tym zakresie Next.js daje dużo więcej.
Porównanie obu podejść szerzej opisałem w artykule Astro.js vs Next.js — które narzędzie wybrać w 2026 roku?.
Praktyczne wskazówki projektowe
Jeśli zaczynasz projekt w Astro, rekomenduję następujący sposób myślenia:
Zaczynaj od zera JS. Każdy komponent traktuj domyślnie jako .astro. Dopiero gdy naprawdę potrzebujesz stanu, zdarzeń lub efektów, sięgaj po React/Vue/Svelte z dyrektywą hydracji.
Wybieraj najmniej agresywną dyrektywę. client:visible powinien być domyślnym wyborem. client:idle dla rzeczy ważnych, ale poniżej viewportu. client:load zostaw dla rzeczy, które muszą działać natychmiast (navbar z dropdownem, hero z CTA).
Nie zawijaj całego layoutu w React. To typowy błąd przy migracji z Next.js: programista przyzwyczajony do _app.tsx opakowuje wszystko w jeden komponent React. W Astro layout powinien być .astro, a Reacta używasz tylko w miejscach, które naprawdę potrzebują interakcji.
Unikaj mapowania dużych list do klienckich wysp. Jeśli masz 100 elementów i każdy jest osobną wyspą React, szybko wracasz do ciężkiego JavaScriptu. Lepiej zrobić jeden kontener-wyspę, który obsłuży listę po stronie klienta.
Pilnuj, żeby wyspy były niezależne. Każda wyspa ma własny kontekst i hydratuje się osobno. Jeśli próbujesz dzielić stan między dwiema wyspami przez React Context, to znak, że model jest źle dobrany. Użyj Zustand/nanostores albo rozważ, czy to naprawdę powinny być dwie osobne wyspy.
Budżet JavaScriptu dla wysp
Największy błąd w Astro to traktowanie client:* jak dekoratora, który można dopisać bez konsekwencji. Każda wyspa wnosi runtime frameworka, kod komponentu i potencjalnie zależności.
| Typ sekcji | Domyślna decyzja | Dlaczego |
|---|---|---|
| Hero z tekstem i obrazem | .astro, bez hydracji | Treść i układ nie potrzebują JS |
| Formularz kontaktowy | React/Svelte z client:visible albo server action | Interakcja jest potrzebna dopiero przy sekcji formularza |
| Menu mobile | Mała wyspa z client:load | Nawigacja musi działać od razu |
| Kalkulator ceny | client:idle lub client:visible | Ważny, ale zwykle nie jest pierwszą interakcją |
| Opinie, logo, FAQ | Statyczny HTML | Interaktywność zwykle nie wnosi wartości |
Islands Architecture a SEO
Z perspektywy SEO architektura wysp ma jedną fundamentalną zaletę: Google i inne roboty indeksujące dostają gotowy HTML bez zależności od JavaScriptu. Nie czekają na renderowanie po stronie klienta, nie przepalają dodatkowo crawl budgetu i nie muszą wyciągać metadanych z dynamicznego kodu. Wszystko, co powinno być zindeksowane, jest w HTML-u już w odpowiedzi serwera.
Dla rankingów oznacza to lepszy punkt startowy pod Core Web Vitals, czystsze dane uporządkowane i mniejsze ryzyko, że ważna treść nie zostanie zindeksowana. Dla GEO/AEO roboty dostają prostszy dokument HTML, z mniejszą liczbą skryptów i mniej złożoną hydratacją, co może pomagać w maszynowym rozumieniu treści. Nie traktowałbym tego jednak jako gwarancji cytowań.
Głębiej temat SEO w Astro rozbieram w osobnym artykule.
Podsumowanie
Architektura wysp nie jest magią ani srebrną kulą. To świadomy kompromis: rezygnujesz z wygody pełnego Reacta na każdym poziomie strony, ale zyskujesz precyzyjną kontrolę nad tym, co naprawdę trafia do przeglądarki. W stronach zorientowanych na treść ta kontrola daje wydajność, którą trudno osiągnąć innym sposobem.
Jeśli Twój następny projekt to blog, dokumentacja, strona firmowa albo portfolio — wyspy dają Ci wymierną przewagę. Jeśli to dashboard albo edytor — prawdopodobnie lepszym wyborem będzie Next.js. A jeśli nie jesteś pewien, porozmawiajmy i pomogę Ci dobrać narzędzie do problemu.
