Astro 6, framework z architektura wysp

Astro 6, framework treściowy z architekturą wysp

Astro renderuje strony do czystego HTML i domyślnie nie wysyła do przeglądarki ani bajta JavaScriptu. Interaktywne fragmenty dokładasz świadomie, jako wyspy, każdą z własnym momentem uruchomienia. Wersja 6.0 wyszła 10 marca 2026 roku i przyniosła wbudowane API do fontów, polityki bezpieczeństwa treści oraz kolekcje treści aktualizowane bez przebudowy strony.

Skąd bierze się zero JavaScriptu

Klasyczny framework SPA wysyła do przeglądarki cały kod potrzebny do zbudowania interfejsu, nawet jeśli strona jest artykułem, w którym nic się nie klika. Astro odwraca tę zasadę: komponent .astro wykonuje się w trakcie budowania albo na serwerze, a do klienta trafia wynik jego działania, czyli HTML.

Wyspa to wyjątek od tej reguły. Komponent w Reakcie, Vue albo Svelte oznaczasz dyrektywą, a Astro dołoży dla niego paczkę JavaScriptu i uruchomi ją zgodnie z wybraną strategią. Reszta strony pozostaje statyczna, więc koszt interaktywności ponosisz punktowo.

Skutek widać w metrykach. Strona treściowa zbudowana w Astro ładuje zwykle kilkadziesiąt kilobajtów zamiast kilkuset, a Largest Contentful Paint schodzi poniżej sekundy na łączu przeciętnej jakości. Dla serwisów, których ruch pochodzi z wyszukiwarki, ma to bezpośrednie przełożenie na pozycje, bo Core Web Vitals wchodzą do oceny strony.

Co zmieniło się w wersji 6

Astro 6.0 ukazało się w marcu 2026 roku, wydanie 6.4 pod koniec maja. Zmiany warte uwagi przy planowaniu aktualizacji:

Fonts API self hostuje i optymalizuje kroje pisma bez konfiguracji. Znika typowy zestaw ręcznych kroków: pobranie plików, generowanie podzbiorów znaków, deklaracja @font-face i preload. Dla polskich znaków diakrytycznych to oszczędność zauważalna w rozmiarze transferu.

Content Security Policy API pozwala opisać politykę bezpieczeństwa w konfiguracji zamiast doklejać nagłówki na poziomie hostingu. Skrypty wstawiane przez framework dostają poprawne skróty automatycznie, co wcześniej bywało powodem, dla którego zespoły rezygnowały z CSP.

Live Content Collections aktualizują treść w momencie żądania, bez przebudowy całego serwisu. To odpowiedź na najczęstszy zarzut wobec generatorów statycznych: literówka w artykule wymagała pełnego builda.

Serwer deweloperski został przepisany na Environment API z Vite, dzięki czemu w trakcie pracy działa ten sam runtime co na produkcji. Różnice między lokalnym dev a wdrożeniem na Cloudflare Workers, Bun czy Deno robią się przez to rzadsze. Kompilator w Ruście był w szóstce opcją za flagą experimental.rustCompiler, obok domyślnego kompilatora napisanego w Go.

Wersja 6 nie jest już najnowsza. Astro 7.0 wyszło 22 czerwca 2026 roku i domyka wątek kompilatora: napisany w Ruście @astrojs/compiler-rs zastąpił poprzednika w Go i działa bez flagi, przetwarzanie Markdowna oraz MDX też przeszło do kodu natywnego, a bundlerem jest Vite 8 z Rolldownem. Twórcy podają skrócenie czasu budowania o 15 do 61 procent na własnych testach. Siódemka jest przy tym surowsza wobec niepoprawnego HTML-a: niezamknięty znacznik zwraca błąd, zamiast być po cichu naprawiony. Zniknął też pakiet @astrojs/db, a wraz z nim polecenia astro db, astro login i astro link. Opisane niżej wyspy, kolekcje i adaptery działają w obu liniach tak samo, więc lektura ma sens także przy projekcie na siódemce.

Instalacja i struktura projektu

npm create astro@latest moj-serwis
cd moj-serwis
npm run dev

Projekt ma cztery katalogi, które trzeba znać: src/pages wyznacza trasy na podstawie plików, src/components trzyma komponenty, src/content treść w Markdownie lub MDX, a public zasoby serwowane bez przetwarzania.

Komponent .astro składa się z części skryptowej między trzema myślnikami i szablonu pod nią.

---
const posty = Object.values(import.meta.glob('../content/blog/*.md', { eager: true }))
const najnowsze = posty.slice(0, 5)
---

<ul>
  {najnowsze.map((post) => (
    <li><a href={post.url}>{post.frontmatter.tytul}</a></li>
  ))}
</ul>

Kod z górnej części wykonuje się na serwerze albo przy budowaniu i nigdy nie trafia do przeglądarki. Możesz w nim sięgnąć do bazy, przeczytać plik albo odpytać API bez ujawniania kluczy.

Wyspy i dyrektywy klienta

Dyrektywa decyduje, kiedy wyspa dostaje JavaScript. Wybór między nimi wpływa na metryki bardziej niż optymalizacja obrazów.

---
import Galeria from '../components/Galeria.jsx'
import MenuMobilne from '../components/MenuMobilne.vue'
---

<Galeria client:visible zdjecia={zdjecia} />
<MenuMobilne client:media="(max-width: 768px)" />

Domyślnym wyborem powinno być client:visible. Jeśli komponent i tak jest widoczny od razu, zachowa się jak client:load, a jeśli leży niżej, jego kod nie zablokuje pierwszego renderowania.

Warto też pamiętać, że wyspa dostaje dane wyłącznie przez propsy, i to takie, które da się zserializować. Funkcja przekazana z części skryptowej do komponentu klienckiego nie przejdzie, a duży obiekt przekazany w całości powiększy HTML, bo Astro musi go umieścić w dokumencie, żeby wyspa mogła się uruchomić. Przekazuj minimum, resztę dociągaj w komponencie.

Astro pozwala mieszać frameworki na jednej stronie, ale rzadko jest to dobry pomysł w produkcie utrzymywanym przez zespół. Dwie biblioteki to dwie paczki runtime i dwa zestawy konwencji. Sensowne wyjątki to migracja albo pojedynczy komponent zewnętrzny.

Content Collections

Kolekcje dają typowany dostęp do treści. Schemat opisuje frontmatter, a Astro sprawdza go przy budowaniu, więc literówka w nazwie pola zatrzymuje build, zamiast wywalać stronę na produkcji.

// src/content.config.ts
import { defineCollection, z } from 'astro:content'
import { glob } from 'astro/loaders'

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    tytul: z.string().max(60),
    opis: z.string().min(120).max(160),
    dataPublikacji: z.date(),
    tagi: z.array(z.string()).default([])
  })
})

export const collections = { blog }

Schemat pisze się w Zodzie, więc walidacja długości tytułu i opisu pod wymogi wyszukiwarki jest kwestią dwóch linii. To prosty sposób, żeby wymusić dyscyplinę SEO na etapie pisania, a nie audytu po wdrożeniu.

Loader glob czyta pliki z dysku, ale kolekcja może równie dobrze pobierać dane z CMS-a albo z bazy. Wersja 6 dokłada wariant aktualizowany przy żądaniu, co pozwala trzymać artykuły w Sanity albo w Contentful bez przebudowy serwisu po każdej korekcie.

Statycznie, na serwerze, czy pośrodku

Astro buduje statycznie, dopóki nie wskażesz inaczej. Renderowanie na serwerze włącza adapter i ustawienie trybu wyjścia, a decyzję można podejmować osobno dla każdej strony.

// astro.config.mjs
import { defineConfig } from 'astro/config'
import vercel from '@astrojs/vercel'

export default defineConfig({
  output: 'server',
  adapter: vercel()
})

---
export const prerender = true
---

Powyższa linia w konkretnej stronie wraca do generowania statycznego mimo globalnego trybu serwerowego. Odwrotnie działa prerender = false przy wyjściu statycznym.

Osobnym mechanizmem są wyspy serwerowe: strona idzie do przeglądarki jako statyczny HTML, a fragmenty zależne od użytkownika dociągają się osobnym żądaniem. Dzięki temu strona produktu może być w całości z cache, a licznik sztuk na magazynie i tak pokaże aktualną wartość.

Adaptery istnieją dla Vercela, Netlify, Cloudflare, Node, Deno i Bun. Wybór platformy zmienia zwykle jedną linię konfiguracji, co odróżnia Astro od frameworków mocniej związanych z jednym dostawcą.

Astro kontra Next.js i pozostali

Podział jest mniej ostry, niż sugerują porównania. Astro obsłuży panel administracyjny, a Next.js zbuduje bloga. Pytanie brzmi raczej, czego jest więcej: treści czytanej przez ludzi i roboty, czy stanu aplikacji zmieniającego się w reakcji na kliknięcia.

Wydajność i SEO w praktyce

Sam framework nie załatwia wyników. Trzy rzeczy robią największą różnicę w projektach, które widziałem.

Obrazy przez komponent <Image /> zamiast surowego <img>. Astro wygeneruje wersje w nowoczesnych formatach i dopisze wymiary, przez co znika przesuwanie układu przy ładowaniu, karane w Cumulative Layout Shift.

Fonty przez wbudowane API zamiast linku do zewnętrznego dostawcy. Odpada jedno połączenie sieciowe i jeden moment, w którym tekst jest niewidoczny.

Skrypty zewnętrzne, czyli analityka, czaty i piksele marketingowe, ładowane po interakcji albo z opóźnieniem. Zdarza się, że projekt z zerowym własnym JavaScriptem wysyła 300 kilobajtów kodu firm trzecich, bo dział marketingu dokłada kolejne narzędzia. Astro nie ma na to wpływu, więc warto ustalić limit i pilnować go w audycie.

Metadane generowane z kolekcji, a nie wpisywane ręcznie w każdą stronę. Jeden komponent SEO czytający pola z frontmattera daje pewność, że każdy artykuł ma tytuł, opis, adres kanoniczny i dane strukturalne. Braki w tych polach wychodzą wtedy przy budowaniu, bo schemat ich wymaga.

Wdrożenie i koszty utrzymania

Serwis w całości statyczny wgrasz na dowolny hosting plików, łącznie z darmowymi planami GitHub Pages, Cloudflare Pages i Netlify. Rachunek zaczyna rosnąć dopiero przy trybie serwerowym, bo wtedy każde żądanie uruchamia funkcję.

Ostatni wiersz jest zwykle najlepszym kompromisem dla sklepu albo serwisu z treścią. Strona idzie z cache i kosztuje grosze, a funkcje uruchamiają się wyłącznie dla fragmentu z ceną albo stanem magazynowym.

Drugą pozycją w rachunku są minuty budowania. Serwis z pięcioma tysiącami podstron potrafi budować się kilkanaście minut, a przy pełnym przebudowaniu po każdej korekcie treści szybko wyczerpuje darmowy limit. Tu wchodzą kolekcje aktualizowane przy żądaniu, bo pozwalają ograniczyć pełne budowanie do zmian w kodzie.

Przy migracji istniejącej strony zaplanuj przekierowania. Astro obsługuje je w konfiguracji, co jest wygodniejsze niż plik reguł na poziomie hostingu, bo trafiają do repozytorium razem z kodem.

export default defineConfig({
  redirects: {
    '/blog/[slug]': '/artykuly/[slug]',
    '/stara-oferta': { status: 301, destination: '/oferta' }
  }
})

Sprawdź listę adresów w Search Console przed wdrożeniem i po nim. Utrata pozycji przy zmianie technologii bierze się w większości przypadków nie z samego frameworka, tylko z porzuconych adresów, które nagle zwracają 404.

Typowe błędy

Pierwszy to dyrektywa client:load wszędzie. Wtedy Astro przestaje się różnić od klasycznej aplikacji, tylko z dodatkową warstwą kompilacji.

Drugi to sięganie po globalny stan między wyspami. Wyspy są osobnymi drzewami komponentów i nie dzielą kontekstu Reacta ani store'a Vue. Wspólny stan trzymaj w bibliotece niezależnej od frameworka albo w parametrach adresu.

Trzeci to trzymanie treści poza kolekcjami. Pliki czytane ręcznie przez glob nie mają walidacji ani typów, więc błąd we frontmatterze wychodzi dopiero na stronie.

Czwarty to pomijanie prerender przy trybie serwerowym. Strony, które mogłyby być w całości statyczne, generują się przy każdym żądaniu i płacisz za to czasem odpowiedzi oraz rachunkiem za funkcje.

FAQ

Czy Astro nadaje się do aplikacji, nie tylko do stron?

Nadaje się, choć nie jest do tego stworzone. Panel z formularzami i widokami zależnymi od stanu wygodniej zbudujesz w Next.js albo SvelteKit. Astro wygrywa tam, gdzie większość widoków to treść, a interaktywność jest wyspami.

Czy mogę używać Reacta w Astro?

Tak, po dodaniu integracji komponenty Reacta działają jako wyspy. Ograniczenie polega na tym, że każda wyspa jest osobnym drzewem: kontekst, provider czy globalny store nie przechodzą między nimi.

Jak wygląda migracja z Next.js?

Trasy przenosi się plik po pliku, bo obie technologie mapują katalog na adresy. Najwięcej pracy wymaga warstwa pobierania danych, ponieważ getStaticProps i Server Components nie mają dosłownego odpowiednika, a ich rolę przejmuje kod w części skryptowej komponentu. Rozsądnie jest zacząć od sekcji treściowej i zostawić panel na później.

Czy Astro obsługuje TypeScript?

Tak, wsparcie jest wbudowane i nie wymaga konfiguracji. Kolekcje treści generują typy na podstawie schematów, więc pola frontmattera są podpowiadane w edytorze, a literówka w nazwie zatrzymuje budowanie.

Czy wersja 6 wymaga przepisania projektu z piątki?

Nie w typowym przypadku. Zmiany dotyczą głównie warstwy wewnętrznej: serwera deweloperskiego i pipeline'u budowania. Przed aktualizacją sprawdź integracje pochodzące od społeczności, bo to one najczęściej wymagają nowej wersji.

Ogłoszenie wydania stoi na blogu Astro, a pełna dokumentacja w docs.astro.build.