Strony w Astro
Astro vs WordPress i Next.js — kiedy wybrać co
Trzy modele renderowania, dane HTTP Archive o Core Web Vitals, macierz decyzyjna i koszt utrzymania — kiedy wybrać Astro, kiedy WordPress, a kiedy Next.js.
Zaktualizowano 2026-09-02
WordPress, Next.js i Astro rozwiązują trzy różne problemy. WordPress daje redakcji pełne zaplecze do zarządzania treścią, Next.js daje aplikację renderowaną po obu stronach, Astro daje statyczny HTML z punktową interaktywnością. Wybór między nimi to nie kwestia mody, tylko odpowiedź na pytanie, czy budujesz stronę treściową, czy aplikację.
Trzy modele renderowania
| Kryterium | WordPress | Next.js | Astro |
|---|---|---|---|
| Gdzie powstaje HTML | PHP na serwerze przy każdym żądaniu (bez cache) | serwer lub build, zależnie od trybu trasy | build, opcjonalnie serwer dla wybranych fragmentów |
| JavaScript wysyłany domyślnie | zależny od motywu i wtyczek, zwykle kilkaset kilobajtów | runtime frameworka + kod strony | zero, poza jawnie oznaczonymi wyspami |
| Edycja treści | panel dla redakcji, bez udziału zespołu dev | headless CMS albo repozytorium | pliki w repozytorium albo headless CMS |
| Utrzymanie | aktualizacje rdzenia, motywu i wtyczek, kopie bazy | aktualizacje zależności, utrzymanie środowiska serwerowego | aktualizacje zależności, hosting statyczny bez serwera aplikacji |
| Naturalne zastosowanie | serwis redakcyjny z wieloma autorami | aplikacja z kontami i stanem | strona firmowa, produktowa, dokumentacja, landing |
Co mówią dane o Core Web Vitals
Raport HTTP Archive Core Web Vitals Technology Report, oparty na rzeczywistych danych Chrome User Experience Report, pokazuje odsetek domen, które przechodzą wszystkie trzy metryki. W danych z 2025 roku domeny zbudowane w Astro przechodziły próg w około 60% przypadków, a domeny na WordPressie w około 46% (httparchive.org — Tech Report).
Ta różnica nie oznacza, że WordPress nie potrafi być szybki — oznacza, że domyślna ścieżka prowadzi w innym kierunku. WordPress obsługuje ponad 40% wszystkich stron w internecie (W3Techs, 2026), w tym ogromną liczbę instalacji z kilkunastoma wtyczkami dokładającymi własne skrypty. Astro startuje z zera JavaScriptu i każdy kilobajt trzeba świadomie dodać.
Progi „dobrego" wyniku to LCP maksymalnie 2,5 s, INP maksymalnie 200 ms i CLS maksymalnie 0,1, liczone na 75. percentylu ruchu. Jak te metryki przekładają się na sprzedaż, rozkładamy na dane w artykule o wydajności i konwersji.
Kiedy WordPress jest właściwym wyborem
WordPress wygrywa tam, gdzie treść publikuje wiele osób nietechnicznych, codziennie, w rozbudowanym obiegu redakcyjnym: portal, serwis informacyjny, duży blog firmowy z harmonogramem publikacji i rolami autor–redaktor–wydawca.
Wygrywa też wtedy, gdy potrzebna funkcja istnieje jako sprawdzona wtyczka, a jej napisanie od zera nie ma uzasadnienia biznesowego. Kosztem jest wydajność i utrzymanie: każda wtyczka to dodatkowy kod, dodatkowe aktualizacje i dodatkowa powierzchnia ataku.
Kiedy Next.js jest właściwym wyborem
Next.js jest właściwy, gdy interfejs sam jest produktem: konta użytkowników, panel z danymi, widoki zależne od sesji, stan współdzielony między ekranami, praca w czasie rzeczywistym.
Wtedy koszt wysłania frameworka do przeglądarki jest uzasadniony, bo aplikacja i tak potrzebuje warstwy klienckiej. Używanie Next.js do strony wizerunkowej z formularzem kontaktowym to płacenie tym kosztem bez korzyści.
Kiedy Astro jest właściwym wyborem
Astro jest właściwe dla stron, w których treść stanowi 90% wartości, a interaktywność jest wyspowa: strona firmowa, produktowa, dokumentacja, baza wiedzy, landing kampanijny, kalkulator, konfigurator, formularz kwalifikujący.
Mechanizm, który to umożliwia — renderowanie do HTML-u w czasie builda i hydratacja wyłącznie oznaczonych komponentów — opisujemy w artykule o architekturze wysp w Astro, a konkretne wdrożenie z pomiarami w studium przypadku aiact.waw.pl.
Macierz decyzyjna
| Sytuacja | Rekomendacja | Dlaczego |
|---|---|---|
| Strona firmowa lub produktowa, treść aktualizowana kilka razy w miesiącu | Astro | statyczny HTML z CDN, brak serwera aplikacji do utrzymania |
| Serwis z codzienną publikacją przez zespół nietechniczny | WordPress albo Astro z headless CMS | decyduje wygoda redakcji i liczba autorów |
| Aplikacja z logowaniem i danymi per użytkownik | Next.js | stan i sesja po stronie klienta są rdzeniem produktu |
| Landing kampanijny, liczy się czas ładowania i koszt | Astro | najmniejszy możliwy transfer, hosting statyczny w cenie pomijalnej |
| Sklep na Shopify z ambicjami wydajnościowymi | headless React albo Astro na froncie | pełna kontrola nad warstwą prezentacji, opisana w artykule o headless Shopify |
Koszt utrzymania i powierzchnia ataku
Strona statyczna nie ma bazy danych, warstwy PHP ani panelu logowania wystawionego na zewnątrz. To usuwa całą klasę incydentów: przejęcia przez podatną wtyczkę, wstrzyknięcia SQL, boty próbujące haseł do panelu. Kopia zapasowa strony statycznej to repozytorium, a wdrożenie cofa się do poprzedniej wersji jednym kliknięciem.
W WordPressie te zadania nie znikają — trzeba je zaplanować i za nie zapłacić: aktualizacje rdzenia i wtyczek, monitoring, kopie bazy, testy po każdej aktualizacji. To realna pozycja w budżecie utrzymania, którą warto policzyć przed wyborem technologii, a nie po pierwszym incydencie.
Checklista wyboru technologii
- Policz, ile podstron faktycznie wymaga treści zmiennej per użytkownik.
- Ustal, kto publikuje treść i jak często — to często rozstrzyga szybciej niż argumenty techniczne.
- Wypisz funkcje wymagające serwera: płatności, logowanie, integracje, generowanie dokumentów.
- Zmierz obecne Core Web Vitals i zapisz je jako punkt odniesienia przed migracją.
- Oszacuj roczny koszt utrzymania każdego wariantu, łącznie z aktualizacjami i hostingiem.
- Sprawdź, czy zespół, który będzie stronę rozwijał, zna wybrany stack.
Najczęstsze błędy przy wyborze
- Wybór narzędzia przed opisaniem procesu. Decyzja zapada na podstawie preferencji wykonawcy, a nie tego, kto i jak często będzie edytował treść.
- Aplikacja kliencka do strony wizerunkowej. Pełny framework w przeglądarce dla pięciu podstron z formularzem to koszt bez zwrotu.
- Migracja bez pomiaru „przed". Bez zapisanych wyników sprzed zmiany nie da się wykazać, czy nowa strona jest faktycznie szybsza.
Najczęściej zadawane pytania
- Czy migracja z WordPressa na Astro oznacza utratę panelu do edycji treści?
- Nie musi. Astro pobiera treść z headless CMS — może nim być nawet dotychczasowy WordPress, używany wyłącznie jako zaplecze redakcyjne. Redakcja pracuje w znanym panelu, a strona, którą widzi użytkownik, jest generowana jako statyczny HTML.
- Czy Astro jest szybsze od Next.js?
- Dla stron treściowych zwykle tak, bo Astro domyślnie nie wysyła do przeglądarki kodu frameworka. Dla aplikacji z kontami i stanem współdzielonym porównanie traci sens — tam warstwa kliencka jest potrzebna, a Next.js jest do niej zaprojektowany.
- Czy da się połączyć WordPressa z Astro?
- Tak. WordPress udostępnia treść przez REST API lub GraphQL, a Astro pobiera ją w czasie budowania i generuje statyczne strony. Taki układ zachowuje wygodę redakcji i usuwa PHP z drogi użytkownika, ale wymaga przemyślenia, kiedy uruchamiać przebudowę strony.
- Czy zmiana technologii zaszkodzi pozycjom w Google?
- Ryzyko wynika nie z technologii, lecz z niedopilnowanej migracji. Adresy URL trzeba zachować albo przekierować kodem 301, przenieść meta dane i dane strukturalne oraz zweryfikować indeksację po wdrożeniu. Wykonana poprawnie migracja zwykle poprawia widoczność przez lepsze Core Web Vitals.
- Ile kosztuje utrzymanie strony statycznej w porównaniu z WordPressem?
- Strona statyczna nie potrzebuje serwera aplikacji ani bazy danych, więc hosting jest wielokrotnie tańszy, a często mieści się w darmowych progach platform. Znika też cykl aktualizacji wtyczek i testów po nich — pozostaje aktualizacja zależności projektu.