Astro czy Next.js na portfolio albo landing page
Kiedy Astro pasuje do portfolio i landing page'a, a kiedy lepszy jest Next.js: dane Core Web Vitals z HTTP Archive i pomiary tej strony.
Na portfolio albo landing page lepszym punktem wyjścia jest Astro: renderuje każdą stronę do HTML z wyprzedzeniem i nie wysyła JavaScriptu, dopóki komponent sam o to nie poprosi. Next.js wygrywa wtedy, gdy strona jest w praktyce aplikacją, z logowaniem, danymi per użytkownik i zapisem po stronie serwera. Ta strona stoi na Astro, a Clockful, tracker czasu pracy zbudowany przeze mnie na stażu w Neoteric, na Next.js.
TL;DR
- Astro do treści: każda strona wyrenderowana do HTML z wyprzedzeniem, domyślnie zero JavaScriptu, interaktywność włączana wyspa po wyspie.
- Next.js do aplikacji: logowanie, role i dane per użytkownik; w statycznym eksporcie traci cookies, przekierowania, Server Actions i nie tylko.
- Publiczne dane: w mobilnych danych HTTP Archive z sierpnia 2026 Core Web Vitals przechodzi 71,0% originów na Astro i 35,1% na Next.js, częściowo dlatego, że na każdym z nich buduje się co innego.
Do czego służy każdy z frameworków?
Dokumentacja Astro mówi wprost, że to framework do stron opartych na treści, takich jak blogi, strony marketingowe i sklepy. Sam siebie nazywa server-first, z zerem JavaScriptu domyślnie. Na tej samej stronie przyznaje, że inne frameworki lepiej radzą sobie z interfejsami przypominającymi aplikacje: panelami po zalogowaniu, skrzynkami pocztowymi, sieciami społecznościowymi i listami zadań.
Next.js przedstawia się jako framework Reacta do budowania aplikacji full-stack. W App Routerze layouty i strony są domyślnie komponentami serwerowymi (React Server Components), a kod kliencki włączasz dyrektywą "use client".
Te dwa opisy rozstrzygają większość sprawy. Portfolio to strona z treścią i formularzem kontaktowym. Dashboard to aplikacja.
Ile JavaScriptu trafia do przeglądarki?
W Astro każdy komponent UI, także reactowy, renderuje się do HTML i CSS, a jego kliencki JavaScript zostaje wycięty. Interaktywność włączasz świadomie, komponent po komponencie, przez wyspy: client:load hydratuje od razu, client:idle, gdy przeglądarka nie ma nic do roboty, client:visible, gdy komponent wjedzie w widok. Strona bez wysp nie ładuje żadnego runtime'u frameworka.
Next.js też renderuje na serwerze, a komponenty serwerowe nie trafiają do bundla. Mimo to w przeglądarce działa React, który hydratuje komponenty klienckie i obsługuje nawigację, a wszystko, co importuje plik z "use client", ląduje w bundlu. W aplikacji z wieloma ekranami i wspólnym stanem to się opłaca; na portfolio z pięcioma podstronami to narzut, którym trzeba zarządzać.
Tak wygląda droga Astro na tej stronie:
- 01 Build Każda strona staje się plikiem HTML, z CSS wpisanym w nagłówek.
- 02 CDN Vercel serwuje pliki; formularz kontaktowy to jedyna funkcja.
- 03 Najpierw tekst H1 to największy element na ekranie i nie czeka na żaden skrypt.
- 04 Małe skrypty Skrypty komponentów to małe moduły, bez runtime'u frameworka.
- 05 Efekty na końcu Pętle i klipy czekają na pierwszą interakcję, shadery rysują tylko w widoku.
Wysp frameworka nie ma tu wcale. Każdy komponent to plik .astro, a interaktywne części (przycisk pauzy, przegląd certyfikatów, pasek z wpisami) to zwykłe skrypty, które Astro pakuje w małe moduły. Na stronie głównej razem mają mniej niż 10 KB po gzipie.
Czy oba dają statyczną stronę?
Tak, ale za inną cenę. W Astro domyślnie cała strona jest renderowana przy buildzie. Jeśli jedna trasa potrzebuje serwera, na przykład endpoint formularza kontaktowego, dodajesz adapter i oznaczasz tę stronę przez export const prerender = false. Reszta zostaje statyczna.
Ta strona obeszła się nawet bez tego: nie ma adaptera, a formularz kontaktowy wysyła dane do zwykłej funkcji Vercel obok statycznych plików (jak działa formularz kontaktowy).
Next.js też potrafi wygenerować statyczną stronę: z output: 'export' polecenie next build zapisuje po jednym pliku HTML na trasę w folderze out. Dokumentacja wylicza, co wtedy tracisz, między innymi cookies, przekierowania, Proxy, Incremental Static Regeneration, Server Actions i dynamiczne trasy bez generateStaticParams(). Wiele z tych rzeczy to właśnie powód, dla którego wybiera się Next.js.
A treść, tłumaczenia i przejścia między stronami?
Portfolio to głównie tekst. Kolekcje treści w Astro wczytują Markdown i MDX z folderów, walidują frontmatter schematem Zod i generują z niego typy TypeScript. Ten wpis to jeden z takich plików: jego tytuł, opis i źródła są sprawdzane, zanim strona się zbuduje. Trzy języki strony obsługuje Lingui, w całości statycznie (jak działa wielojęzyczność tej strony).
Przy przejściach między stronami Astro obsługuje natywne view transitions między dokumentami (reguła CSS @view-transition), a komponent <ClientRouter /> daje przejścia w stylu SPA, gdy chcesz mieć nad nimi większą kontrolę. Ta strona używa tylko reguły CSS: podstrony przenikają się bez JavaScriptu, a kto prosi o ograniczony ruch, przechodzi od razu.
Co mówią publiczne dane?
HTTP Archive Tech Report bierze Core Web Vitals od prawdziwych użytkowników z Chrome UX Report na poziomie originów, a technologie wykrywa na stronie głównej i jednej podstronie każdej witryny. Astro i Next.js w danych z sierpnia 2026, mobile, wszystkie originy:
| Mobile, sierpień 2026 | Astro | Next.js |
|---|---|---|
| Zbadane originy | 43 850 | 374 612 |
| Dobre Core Web Vitals (LCP, INP, CLS) | 71,0% | 35,1% |
| Dobre LCP | 80,6% | 53,1% |
| Mediana JavaScriptu na stronę | 405 KB | 853 KB |
Traktuj to jako obraz dwóch populacji, a nie wyrok na dwa frameworki. Według ich własnej dokumentacji Next.js celuje w aplikacje, a Astro w strony z treścią, więc część różnicy wynika z tego, co ludzie na nich budują. Raport nie oddzieli frameworka od strony, która na nim stoi.
Co zmierzyłem na tej stronie?
Ta strona to Astro 7, Tailwind 4 i jeden font zmienny, wdrożona jako statyczne pliki na Vercelu.
Dwie uczciwe uwagi:
- Nie zbudowałem tej samej strony w Next.js, więc nie powiem Ci, ile by dostała. Dlatego porównanie wyżej opiera się na publicznych danych.
- Sam framework tego wyniku nie wypracował. Po południu 7 października strona główna spadła do 67-74, choć żaden kod frameworka nie był w to zamieszany: pętle animacji działające w trakcie ładowania, klasa, która przeliczała style każdego elementu w sekcjach poza ekranem, i skrypty wymuszające układ. Naprawa tych trzech rzeczy przywróciła wynik. Astro dało mi punkt startu: zero JavaScriptu, więc nie było czego wycinać.
Ten sam wzór widać w pomiarach Lighthouse 16 portfolio programistów: immersyjne strony 3D wypadły dużo gorzej od minimalistycznych. Całą historię budowy opisuję w tekście jak powstała ta strona.
Od tamtej pory zmierzyłem jedną prawdziwą przeprowadzkę: stronę klienta yws.lu, którą zbudowałem w Next.js w 2025 roku. Miała 23-45 punktów wydajności w Lighthouse, a po przebudowie w Astro 94-100 (Lighthouse 13.5, lokalnie, mediana z 3 pomiarów). Szczegóły są w case study yws.lu.
Kiedy wybrać Next.js?
Wybierz Next.js, gdy większość ekranów zależy od tego, kto na nie patrzy. Clockful, tracker czasu pracy z rolami, który zbudowałem na stażu w Neoteric, jest właśnie takim projektem: logowanie, role, dane per użytkownik i row-level security w Postgresie na każdej tabeli.
Dokumentacja Next.js opisuje ten obszar w jednym przewodniku: uwierzytelnianie, sesje w cookies, autoryzację w warstwie dostępu do danych i Server Actions do zapisu. Astro też umie renderować na żądanie, ale jego własna dokumentacja przy panelach po zalogowaniu wskazuje inne frameworki. Next.js wygrywa też wtedy, gdy landing page należy do istniejącego produktu na Next.js: jedno repozytorium jest lepsze niż dwa stacki dla jednej strony marketingowej.
Kiedy wybrać Astro?
Gdy treść jest najważniejsza: portfolio, landing page, dokumentacja, blog, strona małej firmy. Tam, gdzie potrzebujesz interakcji, możesz pisać w React, Preact, Svelte, Vue albo SolidJS, a kod wysyłają tylko te wyspy. Hosting to CDN plus build, a funkcję serwerową dodajesz tylko tam, gdzie jest potrzebna.
Który pasuje do Twojej strony?
| Twoja strona | Wybierz | Dlaczego |
|---|---|---|
| Portfolio, CV, blog | Astro | Statyczny HTML, zero JS domyślnie, kolekcje treści |
| Marketingowy landing page | Astro | To samo, plus wyspa na jeden interaktywny element |
| Landing page w produkcie na Next.js | Next.js | Jedno repozytorium, jedno wdrożenie |
| Dashboard z logowaniem i rolami | Next.js | Komponenty serwerowe, przewodnik po auth, Server Actions |
| Aplikacja z danymi użytkownika na każdym ekranie | Next.js | Zbudowany pod renderowanie na żądanie |
| Strona z treścią i jedną lub dwiema dynamicznymi trasami | Astro | Domyślnie statyczna, prerender = false per trasa |
Jak zdecydować u siebie?
Spisz, co strona ma robić w pierwszym roku. Jeśli na liście jest „logowanie”, „dashboard” albo „dane użytkownika”, zacznij od Next.js. Jeśli lista brzmi „podstrony, wpisy, formularz kontaktowy”, zacznij od Astro i mierz na telefonie ze średniej półki.
Resztę tego, co zbudowałem, znajdziesz na stronie z moimi projektami, a Clockful, aplikację z rolami, w moim CV.
Źródła
- Astro docs: Why Astro? (otwiera się w nowej karcie) (dostęp: )
- Astro docs: Islands architecture (otwiera się w nowej karcie) (dostęp: )
- Astro docs: On-demand rendering (otwiera się w nowej karcie) (dostęp: )
- Astro docs: Content collections (otwiera się w nowej karcie) (dostęp: )
- Astro docs: View transitions (otwiera się w nowej karcie) (dostęp: )
- Next.js docs: Introduction (otwiera się w nowej karcie) (dostęp: )
- Next.js docs: Server and Client Components (otwiera się w nowej karcie) (dostęp: )
- Next.js docs: Static exports (otwiera się w nowej karcie) (dostęp: )
- Next.js docs: Authentication (otwiera się w nowej karcie) (dostęp: )
- HTTP Archive Tech Report: about the data (otwiera się w nowej karcie) (dostęp: )
- HTTP Archive Tech Report: Astro vs Next.js (otwiera się w nowej karcie) (dostęp: )