Astro 5+

Brief praktyka

Dlaczego to wdrożyliśmy

Przenieśliśmy wppoland.com z Next.js 13 pages-router na Astro 5 w marcu 2026. LCP na stronie głównej spadło z 2,4 s do 1,1 s na profilu Moto G Power, bundle JS na stronie treściowej zmalał ze 187 KB gzip do 9 KB (jedna wyspa Search), a czas pełnego cold-buildu z 11 min 30 s na Vercelu do 7 min 30 s lokalnie przy 16 GB heapu w scripts/stable-build.sh. Content Layer API (RFC 0050, Astro 5.0) traktuje MDX, JSON i treść zdalną jako jedną powierzchnię getCollection, co zwija trzy adaptery z czasów Next.js.

Kiedy po nie sięgamy

Powierzchnie marketingowe oparte na treści: strony filarowe, macierze porównawcze, programatyczne strony miast, dokumentacja, blogi. Render w większości statyczny, wyspy odizolowane (wyszukiwarka, przełącznik cennika, wykres), pętla redakcyjna przez Markdown plus kolekcje MDX. Nie sięgamy po Astro, gdy brief ma kształt aplikacji: dashboardy za logowaniem, checkout ze współdzielonym stanem koszyka, wszystko, gdzie właściwym modelem jest React renderowany po stronie klienta albo streaming RSC. Do tego zostajemy przy Next.js 15.

Ścieżka migracji

Większość zespołów przychodzi z Next.js 13/14 pages router (najczystsza ścieżka, getStaticProps mapuje się niemal 1:1 na kolekcje Astro), z Gatsby v5 (schemat GraphQL to najtrudniejsza część, router plikowy i MDX przenoszą się bez problemu) albo z monolitu WordPress idącego w headless (potraktuj to jak greenfield, podepnij WPGraphQL lub REST). Co się nie przenosi: React context, stan wyłącznie kliencki (Zustand, Jotai), middleware Next.js. Zaplanuj około 1 dzień na 30 stron treści plus twardy tydzień na konwersję powłoki z Reacta na Astro.

Dwie blizny z produkcji

Po pierwsze, View Transitions na iOS Safari 17.4: kliknięcie linku sterowanego przez MDX w trakcie przejścia uruchamiało skrypty nowych wysp, zanim stary DOM został podmieniony, więc nieaktualne listenery zostawały podpięte i wyszukiwarka przestawała działać przy drugiej nawigacji. Obejście: transition:persist="search" i <ClientRouter /> zamiast starego importu <ViewTransitions /> (Astro PR #12029 ustabilizował to w 5.2). Po drugie, MDX plus remark-shiki na buildzie Cloudflare Pages: shiki próbował załadować ponad 90 gramatyk i wywalił 4 GB workera na OOM. Poprawka: przypięcie shikiConfig.langs do ['ts', 'js', 'php', 'json', 'bash']. Pamięć buildu spadła z 3,8 GB do 1,2 GB.

Co obserwujemy

Server Islands (Matthew Phillips, RFC 0040, w 5.0) to droga do selektywnej dynamicznej personalizacji wewnątrz statycznej strony. Pilotujemy je na przełączniku cennika, ale wstrzymujemy się z wdrożeniem na całej witrynie, dopóki nie ustabilizują się nagłówki cache'owania (astro/#11437). Container API do testowania komponentów pod vitest jest na naszej krótkiej liście, gdy tylko wejdzie PR #11952 Bjorna Lu. Oraz Astro DB: Turso odkupiło je na początku 2026, a historia migracji dla stron używających astro:db wciąż pozostaje otwarta (astro/#12188).

Dalsza lektura

• Next.js vs Astro: matryca decyzji