Astro — framework do stron statycznych i SEO

Czym jest Astro?

Astro to framework do budowy szybkich stron opartych na treści — blogów, dokumentacji, stron docelowych i sklepów internetowych. Twórcy zaprezentowali go w czerwcu 2021 r. (blog Astro, 8 czerwca 2021), a wersja 1.0 ukazała się w sierpniu 2022 r. (blog Astro, 9 sierpnia 2022). Główna idea: domyślnie żadnego JavaScriptu w przeglądarce — strony powstają z góry jako czysty HTML, a JavaScript ładuje się tylko tam, gdzie jest potrzebny (architektura wysp).

Astro jest pomyślany jako alternatywa dla Next.js i Nuxt w serwisach, w których najważniejsza jest treść; Next.js i Nuxt są nastawione bardziej na aplikacje.

Kluczowe cechy

• Wiele frameworków naraz — na jednej stronie możesz łączyć komponenty React, Vue, Svelte i Solid
• Architektura wysp — interaktywne komponenty (wyspy) uruchamiają się w przeglądarce osobno, reszta strony to czysty HTML
• Obsługa MDX — treść piszesz w Markdownie z komponentami JSX
• Generowanie statyczne jako tryb domyślny — podczas budowania strony zamieniają się w statyczny HTML
• Opcjonalne renderowanie na serwerze — adaptery dla Vercel, Netlify i Cloudflare obsługują dynamiczne ścieżki
• Wbudowana optymalizacja obrazów — komponent <Image> z automatyczną konwersją do WebP i AVIF
• Mapa witryny, RSS i kolekcje treści — gotowe rozwiązania, bez pisania ich od zera
• TypeScript od początku — pełna obsługa typów

Astro SSG: kiedy wystarczą strony statyczne, a kiedy potrzebny jest serwer

Astro domyślnie działa jako generator stron statycznych (SSG): podczas budowania zamienia każdą podstronę w gotowy plik HTML, który można wgrać na zwykły serwer plików albo do sieci CDN. Renderowanie na serwerze, przy każdym wejściu, włącza się dopiero wtedy, gdy strona naprawdę go potrzebuje — i tylko dla wybranych podstron, a nie dla całego serwisu.

W praktyce wygląda to tak:

• Tryb domyślny — polecenie astro build tworzy statyczne pliki dla wszystkich stron. Strony z dynamicznym adresem, np. wpis bloga pod /blog/[slug], muszą wtedy z góry podać listę adresów przez getStaticPaths(). Robot wyszukiwarki dostaje pełny HTML i nie musi wykonywać JavaScriptu, żeby zobaczyć treść.
• Pojedyncze strony renderowane na żądanie — po dodaniu adaptera dla wybranego środowiska serwerowego wystarczy w pliku strony dopisać export const prerender = false. Reszta serwisu nadal pozostaje statyczna.
• Cały serwis na serwerze — ustawienie output: 'server' odwraca tę logikę: domyślnie wszystko renderuje się na żądanie, a statyczne zostają tylko strony oznaczone do wygenerowania z góry.

Samo SSG wystarcza, gdy treść jest taka sama dla każdego odwiedzającego i zmienia się w rytmie publikacji: blog, dokumentacja, strona firmowa, słownik pojęć. Nowy artykuł oznacza wtedy ponowne zbudowanie i wgranie strony. Formularz kontaktowy może wysyłać dane do osobnej funkcji lub zewnętrznej usługi, więc sam w sobie nie wymusza przejścia na serwer.

Renderowanie na serwerze jest potrzebne, gdy odpowiedź zależy od konkretnego żądania: logowanie i panel klienta, koszyk, treść zależna od ciasteczek, ceny lub stany magazynowe pobierane w chwili wejścia, wyniki wyszukiwania i filtrów. Wtedy dochodzi środowisko serwerowe, które trzeba utrzymywać — dlatego w Astro warto przełączać na serwer tylko te podstrony, które naprawdę tego wymagają.

Astro vs Next.js

Aspekt	Astro	Next.js
Główne zastosowanie	Strony z treścią (blogi, dokumentacja)	Aplikacje webowe i strony z treścią
JavaScript w przeglądarce	Domyślnie brak, tylko w interaktywnych wyspach	Kod frameworka ładowany na każdej stronie
Hydratacja	Częściowa (wyspy)	Cała strona albo React Server Components
Czas budowania	Bardzo szybki	Wolniejszy przy dużych serwisach
Routing	Oparty na plikach	Oparty na plikach
Endpointy API	Ograniczone (przez adapter serwerowy)	Pełne
Optymalizacja obrazów	Wbudowana	Wbudowana (sharp)
Próg wejścia	Łagodny	Stromy (React Server Components, App Router)
Core Web Vitals	Mniej JavaScriptu do wykonania w przeglądarce	Wynik zależy od ilości JavaScriptu i konfiguracji

Werdykt: Astro dla blogów, dokumentacji i stron docelowych. Next.js dla aplikacji SaaS i paneli z danymi.

Astro a SEO

Astro dobrze pasuje do stron opartych na treści, ponieważ:

• Statyczny HTML → Googlebot dostaje gotową treść i nie musi renderować JavaScriptu
• Mało JavaScriptu → przeglądarka ma mniej pracy przy ładowaniu i obsłudze strony
• Mapa witryny → generowana automatycznie z listy stron
• Łatwe dane strukturalne → pełny JSON-LD renderowany po stronie serwera
• MDX na blogu → frontmatter i treść w jednym pliku
• Kolekcje treści → treść z kontrolą typów

Z czym zwykle łączy się Astro

• Hosting: Cloudflare Pages, Vercel, Netlify
• CMS: Sanity, Contentful, Hygraph albo pliki Markdown w repozytorium
• Style: Tailwind CSS, moduły CSS
• Wyszukiwarka: Pagefind (wyszukiwanie statyczne), Algolia DocSearch
• Formularze: Cloudflare Workers, Netlify Forms, Formspree
• Analityka: Plausible, Fathom, Google Analytics

Wydajność

Astro domyślnie nie wysyła do przeglądarki JavaScriptu poza interaktywnymi wyspami, więc przeglądarka ma mniej kodu do pobrania i wykonania niż przy frameworkach, które ładują kod całej aplikacji. To dobry punkt wyjścia do szybkiego ładowania i płynnej reakcji strony, ale wynik konkretnego serwisu zależy też od obrazów, czcionek, skryptów zewnętrznych i hostingu — ocenia się go na danych z rzeczywistych wizyt, a nie na deklaracjach frameworka.

Kiedy NIE używać Astro?

• Aplikacje SaaS z rozbudowanym stanem → Next.js / Remix
• Aplikacje czasu rzeczywistego (czat, panele z danymi) → Next.js z Server Actions
• Sklep z koszykiem działający jako SPA → Next.js z React Query
• Marketplace z rozbudowaną wyszukiwarką i filtrami → Next.js

Powiązane pojęcia

• Cloudflare Pages — popularna platforma hostingu stron statycznych
• Core Web Vitals — wskaźniki, na które wpływa ilość JavaScriptu na stronie
• SEO — Astro od początku generuje HTML gotowy do indeksowania
• Lighthouse — laboratoryjne narzędzie do audytu strony
• Static site generation — model, na którym opiera się Astro
• Information gain — treść strony w Astro jest od razu dostępna dla wyszukiwarek