WordPress 7.0 vs Astro 7 na Cloudflare - kto wygrywa w 2026?

Dla większości stron biznesowych Astro 7 na Cloudflare jest tańszy, szybszy i łatwiejszy do zabezpieczenia niż WordPress 7.0. Ale ta przewaga ma cenę, o której poprzednia wersja tego porównania milczała: framework ma własny cykl wydawniczy i ktoś musi za niego zapłacić czasem.

To porównanie pisałem pierwszy raz w kwietniu, przy Astro 6 i WordPressie 7.0 w fazie RC. Od tego czasu obie platformy weszły w produkcję, a my przenieśliśmy tę stronę z Astro 6 na Astro 7. Mam więc coś, czego wtedy nie miałem: rachunek za migrację między dwiema dużymi wersjami frameworka, wystawiony na własnym korpusie kilkunastu tysięcy stron.

Wnioski co do wyboru platformy się nie zmieniły. Zmieniło się to, ile wiem o kosztach ukrytych po stronie Astro.

#WordPress 7.0 trzy miesiące po premierze

WordPress 7.0 wyszedł 20 maja 2026. Warto oddzielić to, co zapowiadano, od tego, co faktycznie znalazło się w paczce.

#AI Client i Abilities API

AI Client to infrastruktura, nie gotowy AI writer. WordPress 7.0 dostarcza jednolite API do komunikacji z modelami, ale wymaga zewnętrznego klucza i konfiguracji. Abilities API pozwala agentom odkrywać i wywoływać funkcje WordPressa programowo, co jest ciekawe dla autorów wtyczek i praktycznie niewidoczne dla redaktora.

To ważny fundament. To nie jest funkcja, którą klient zobaczy w panelu pierwszego dnia.

#Real-time collaboration nie weszło

Współpraca w czasie rzeczywistym była najgłośniejszą zapowiedzią tego wydania i została z niego wycofana po problemach technicznych. Trzy miesiące później nadal nie ma jej w linii 7.0. Jeśli ktoś sprzedawał klientowi WordPressa 7.0 obietnicą jednoczesnej edycji przez wielu redaktorów, ma teraz niewygodną rozmowę do odbycia.

#Architektura pod spodem się nie ruszyła

Odświeżony panel administracyjny i nowe bloki to krok naprzód wizualnie. Pod spodem nadal jest PHP, MySQL i tradycyjny serwer, który trzeba aktualizować, cache’ować i pilnować. Żadna z nowości 7.0 nie zmienia tego, że każda wtyczka powiększa powierzchnię ataku, a wydajność wymaga agresywnej optymalizacji.

#Plusy i minusy WordPress 7.0

Plusy:

• Najlepszy edytor treści dla osób nietechnicznych, bez konkurencji w tej kategorii
• Ekosystem wtyczek liczony w dziesiątkach tysięcy pozycji
• WooCommerce jako kompletna platforma e-commerce
• Abilities API jako fundament pod integracje z agentami

Minusy:

• Rozmiar samego core i narzut, którego nie da się wyłączyć
• Powierzchnia ataku rosnąca z każdą wtyczką
• Koszty hostingu, backupów, monitoringu i wtyczek bezpieczeństwa
• Wydajność osiągalna dopiero po warstwie cache i CDN
• Aktualizacje bezpieczeństwa co kilka tygodni

#Astro 7 i co się realnie zmieniło względem szóstki

Astro 7.0.0 ukazało się 22 czerwca 2026, 104 dni po Astro 6.0.0. Trzy zmiany mają konsekwencje, których nie widać w changelogu, dopóki nie odpalisz własnego builda.

#Kompilator Rust przestał być eksperymentem

W Astro 6 kompilator napisany w Rust był opcją do przetestowania. Astro 7 wymienia zależność @astrojs/compiler na @astrojs/compiler-rs i robi z tego domyślne zachowanie. Buildy są szybsze, ale parser jest ostrzejszy.

U nas wywaliło się na jednej linii. Komentarz HTML zapisany wewnątrz wyrażenia JSX, coś w rodzaju {import.meta.env.DEV && ( <!-- ... --> )}, przechodził przez stary kompilator i jest odrzucany przez nowy. Poprawka to zamiana na komentarz JavaScript. Minuta pracy, pod warunkiem że wiesz, czego szukasz, bo komunikat błędu wskazuje pozycję w kodzie skompilowanym, a nie w źródle.

#Vite 8 pod spodem

Astro 6 stało na Vite 7. Astro 7 przeskakuje na Vite 8, czyli na linię opartą o Rolldown. Dla większości projektów to zmiana niewidoczna, ale przy dużych korpusach warto obserwować zużycie pamięci przy buildzie, bo profil alokacji jest inny niż wcześniej.

#CSP hashuje style inline i to jest pułapka

To jest ta zmiana, która kosztowała nas cały dzień.

Astro 7 automatycznie liczy hashe dla arkuszy <style> osadzonych w stronie i wstawia je do dyrektywy style-src. Zgodnie ze specyfikacją Content Security Policy obecność jakiegokolwiek hasha w dyrektywie unieważnia 'unsafe-inline'. Efekt: wszystkie dynamiczne atrybuty style="" przestają działać. U nas poleciały kolory tokenów Shiki w blokach kodu, zmienne motywu, prędkości animacji i tła. Sama strona główna dała 26 naruszeń CSP, a ucierpiała każda podstrona z podświetlaną składnią.

Nie da się tego wyłączyć przełącznikiem. Nie pomaga też samo 'unsafe-hashes', bo pokrywa atrybuty stylu, ale nie treść elementów <style>.

Rozwiązanie okazało się prostsze, niż wyglądało, bo zbiór stylów inline jest skończony. Przy około 260 tysiącach wystąpień w całym korpusie unikalnych wartości było 143. Wystarczyło je raz zebrać, wpisać hashe do konfiguracji i dołożyć 'unsafe-hashes' dla przypadku atrybutów. Po tym zabiegu naruszeń jest zero na wszystkich typach szablonów.

Zostaje jednak zobowiązanie na przyszłość: każdy nowy komponent, który wprowadzi nową wartość stylu inline, trafi na listę albo zostanie po cichu zablokowany w produkcji. Trzeba na to bramkę w CI, inaczej dowiesz się o problemie z zgłoszenia użytkownika.

#Nowy domyślny pipeline markdown

Astro 7 zmienia domyślne przetwarzanie markdown. Jeśli masz własny łańcuch remark i rehype, trzeba jawnie dociągnąć @astrojs/markdown-remark, żeby zachować dotychczasowe zachowanie. To jednolinijkowa zmiana w zależnościach, ale przeoczona daje cichą różnicę w renderze, a nie błąd builda, więc łatwo ją przegapić.

#Ile realnie kosztowała nas migracja Astro 6 na 7

Liczby z naszego własnego wdrożenia, nie z dokumentacji.

Trzy z czterech nagłówkowych zmian łamiących nas nie dotyczyły i to jest sedno sprawy. Nie mamy Astro DB, nie mamy adaptera serwerowego do przeniesienia i budujemy statycznie, więc reorganizacja wejścia serwerowego nas ominęła. Projekt, który stoi na SSR z adapterem i bazą Astro, ma zupełnie inny rachunek za tę samą migrację.

Wniosek praktyczny: koszt dużej wersji Astro nie skaluje się z rozmiarem strony, tylko z liczbą punktów styku z runtime’em. Nasze kilkanaście tysięcy podstron kosztowało mniej niż kosztowałaby jedna aplikacja z Astro DB i własnym adapterem.

#Bezpośrednie porównanie 2026

Wynik: Astro 7 do 3, jeden remis.

WordPress odzyskał w tej edycji jeden punkt i to nie przez nową funkcję, tylko przez stabilność tempa wydawniczego. Strona na WordPressie sprzed trzech lat nadal się buduje, bo nie ma builda. Strona na Astro sprzed trzech lat stoi dwie wersje major wstecz i ktoś musi ją przeprowadzić.

#Kiedy migrować w 2026, checklista 8 punktów

Migracja ma sens, gdy spełniasz przynajmniej pięć z ośmiu kryteriów:

1. Strona contentowa, blog albo landing page, czyli dokładnie to, do czego Astro powstało
2. PageSpeed poniżej 80 mimo optymalizacji WordPressa, co oznacza problem architektoniczny, nie konfiguracyjny
3. Koszty hostingu przekraczające 200 zł miesięcznie
4. Powtarzające się incydenty bezpieczeństwa, łatanie wtyczek, ataki brute force
5. Zespół deweloperski zna JavaScript i TypeScript oraz zostanie z projektem na tyle długo, żeby przeprowadzić następną wersję major
6. Nie potrzebujesz WooCommerce ani rozbudowanego panelu użytkownika
7. SEO jest priorytetem, a Core Web Vitals wpływają na pozycje
8. Strona działa w wielu krajach i zależy ci na niskim TTFB globalnie

Punkt piąty rozszerzyłem względem kwietniowej wersji tej listy i zrobiłem to świadomie. Znajomość JavaScriptu w dniu wdrożenia nie wystarcza. Liczy się to, kto odpali npm update za dziewięć miesięcy.

Trzy punkty lub mniej: zostań przy WordPressie. Cztery: rozważ hybrydę. Pięć i więcej: migracja się opłaci.

#Case study, przed i po

#Serwis korporacyjny, klient z Warszawy

Przed: WordPress z Elementorem, PageSpeed na czerwono na urządzeniach mobilnych, czas ładowania liczony w sekundach, stała miesięczna pozycja za hosting.

Po: Astro na Cloudflare Pages, PageSpeed na zielono, czas ładowania grubo poniżej sekundy, hosting statyczny na darmowym planie.

Efekt netto: pozycja kosztowa za hosting zniknęła, a Core Web Vitals przeszły z czerwonego na zielony na głównych szablonach. Ten sam serwis przeszedł potem migrację z Astro 6 na 7 w ramach naszego utrzymania i klient nie zauważył nic poza jednym deployem.

#wppoland.com, ta strona

Ponad czternaście tysięcy prerenderowanych podstron w sześciu językach, z czego około trzech tysięcy trafia do sitemap jako treść przeznaczona do indeksowania. Reszta to fan-out miasto razy usługa z noindex. Hosting na darmowym planie Cloudflare. Wcześniej ta sama strona stała na WordPressie z płatnym hostingiem miesięcznym.

Migracja z szóstki na siódemkę na tym korpusie to było pięć plików i jeden dzień pracy, głównie na Content Security Policy.

#Gdzie fizycznie stoi strona i kto odbiera telefon

W polskich projektach jest wątek, którego nie widać w tabeli porównawczej, a który potrafi przeważyć decyzję: klient rzadko kupuje sam hosting. Kupuje pakiet, w którym siedzi domena, poczta firmowa, DNS i wsparcie po polsku, najczęściej u jednego z krajowych dostawców. Strona jest tylko jednym z elementów tego pakietu.

Migracja na Cloudflare Pages rozbija ten pakiet na części i trzeba to powiedzieć klientowi, zanim zacznie się robota, a nie w dniu przełączania DNS:

• poczta firmowa zostaje tam, gdzie była, więc rekordy MX trzeba przenieść świadomie, razem z SPF i DKIM
• panel DNS przenosi się do Cloudflare, więc osoba, która dotąd klikała w panelu dostawcy, traci swoje przyzwyczajenia
• wsparcie przestaje być rozmową telefoniczną po polsku i staje się zgłoszeniem po angielsku
• pozycja za hosting znika z listy kosztów, ale pojawia się rozliczenie u dostawcy, który nie wystawia dokumentu w tej samej formie co dotychczasowy

Dla części klientów to zaleta, bo pakiet i tak był fikcją, a wsparcie sprowadzało się do restartu serwera. Dla części to realna strata. W firmie, w której stronę aktualizuje ta sama osoba, która zakłada skrzynki pracownikom, rozbicie tego na dwa panele i dwa kanały kontaktu jest kosztem organizacyjnym, nie technicznym, i nikt go nie wpisuje do wyceny.

Zasada, którą stosujemy: jeśli klient ma własny dział IT albo stały kontakt z agencją, rozdzielenie warstw jest korzystne, bo każdą z nich można potem wymienić osobno. Jeśli całość trzyma jedna osoba nietechniczna, lepiej zostać przy WordPressie u obecnego dostawcy albo przenieść do Cloudflare wyłącznie warstwę serwowania i zostawić pocztę oraz domenę bez zmian.

#Jak wygląda migracja WordPress do Astro w praktyce

#Krok 1, audyt strony WordPress

Policz custom post types, spisz wtyczki wraz z ich faktyczną funkcją, zmapuj szablony. To determinuje złożoność całej reszty.

#Krok 2, eksport treści

WP CLI albo REST API do wyciągnięcia wpisów, stron i mediów do markdown lub JSON. Większość pracy da się zautomatyzować.

#Krok 3, budowa szablonów Astro

Odtworzenie layoutów i komponentów w składni .astro. Tailwind CSS działa identycznie. Większość szablonów WordPressa ma bezpośrednie odpowiedniki.

#Krok 4, Content Collections

Konfiguracja typów treści z walidacją Zod. Odpowiednik custom post types, tylko z typowaniem, które łapie błąd w czasie builda zamiast na produkcji.

#Krok 5, hosting i DNS

Cloudflare Pages, połączenie z repozytorium Git, konfiguracja domeny. Build odpala się przy każdym pushu.

#Krok 6, redirecty jeden do jednego

Mapowanie wszystkich starych URL-i na nowe ścieżki. To jest ten krok, na którym najczęściej giną pozycje, jeśli zostanie zrobiony pobieżnie.

#Krok 7, testy i zgłoszenie do GSC

Pełny crawl, testy Lighthouse na każdym typie szablonu, nowa sitemapa w Google Search Console.

#Krok 8, monitoring przez 30 dni

Śledzenie pozycji, indeksacji i Core Web Vitals przez pierwszy miesiąc.

Do tej listy dopisałbym dziś krok dziewiąty: zapisz w dokumentacji projektu, którą wersję Astro wdrożyłeś i co trzeba sprawdzić przy następnej dużej. Runbook napisany w dniu migracji zajmuje godzinę. Odtworzenie tej wiedzy pół roku później zajmuje dzień.

#Rozwiązanie hybrydowe, WordPress plus Astro

Nie musisz wybierać jednego z dwóch. Architektura hybrydowa wygląda tak:

• WordPress jako headless CMS, czyli panel administracyjny do treści
• Astro jako frontend generujący statyczne strony z danych WordPressa
• WPGraphQL albo REST API jako most
• Cloudflare Pages jako hosting frontendu

Redaktorzy pracują w znanym interfejsie, użytkownicy dostają statyczną stronę, deweloperzy mają nowoczesny stack. Szerzej rozkładamy ten wybór na czynniki pierwsze w przewodniku po kosztach headless kontra monolit.

#Ukryty koszt, o którym nie pisałem w kwietniu

Astro 6.0.0 wyszło 10 marca 2026. Astro 7.0.0 wyszło 22 czerwca. Do końca sierpnia linia 7.x doszła do 7.2.8. To jest tempo, którego WordPress nie ma i nigdy nie miał.

Dla nas to akceptowalne, bo utrzymujemy własny stack i mamy bramki w CI, które wychwytują dryf, zanim wyjedzie na produkcję. Dla klienta, który dostał stronę i zniknął na dwa lata, to zupełnie inna historia. Strona nadal działa, bo statyczny HTML nie przestaje działać. Ale próba dołożenia czegokolwiek po dwóch latach oznacza przeskok o dwie wersje major naraz, a to jest znacznie trudniejsze niż dwie migracje po kolei.

Uczciwa wersja rekomendacji brzmi więc tak: Astro wygrywa na wydajności, kosztach infrastruktury i bezpieczeństwie, a WordPress wygrywa na tym, że można go zostawić samemu sobie na dłużej. Jeśli w budżecie utrzymania nie ma pozycji na przeglądy techniczne, ta druga cecha jest warta więcej, niż wygląda w tabeli.

#Ślad energetyczny i raportowanie CSRD

W polskich spółkach objętych raportowaniem zrównoważonego rozwoju wedle CSRD zaczyna się pojawiać pytanie o ślad energetyczny serwisu. Warto od razu oddzielić to, co da się wykazać, od tego, co brzmi dobrze w ofercie.

Mechanizm jest rzeczywisty i łatwy do wyjaśnienia audytorowi. Każde wywołanie strony dynamicznej w WordPressie uruchamia proces PHP-FPM i zapytania do MySQL, więc odsłona zużywa cykle procesora w centrum danych. Strona statyczna wychodzi z pamięci podręcznej na brzegu sieci i w typowym trafieniu w cache nie angażuje procesu aplikacyjnego wcale. Kierunek różnicy nie budzi wątpliwości.

Wątpliwości budzi liczba. Nie podajemy klientom procentowej redukcji zużycia energii, bo nie mamy jej z pomiaru, a wartości krążące po materiałach marketingowych nie mają publikowanej metodyki. Jeśli w raporcie ma stanąć konkretna liczba, musi pochodzić z danych dostawcy hostingu za dany okres, a nie z porównania architektur.

Praktyczna rada: do raportu bierz to, co dostawca faktycznie publikuje o swojej infrastrukturze i miksie energetycznym, i cytuj to jako jego deklarację, nie jako własny pomiar. Sama zmiana architektury na statyczną jest argumentem o zużyciu zasobów, nie certyfikatem środowiskowym.

#Moja prognoza na 2026-2027

WordPress zostaje królem dla sklepów WooCommerce, stron z nietechnicznym zespołem redakcyjnym, projektów opartych o gotowe wtyczki i firm, które potrzebują wystartować szybko i tanio.

Astro z Cloudflare przejmuje strony contentowe i blogi z naciskiem na wydajność, serwisy korporacyjne i landing pages, dokumentację techniczną oraz serwisy wielojęzyczne z globalnym zasięgiem.

Moja szacunkowa prognoza sprzed pół roku mówiła o 30-40% rynku stron content-driven przejętych przez frameworki statyczne do końca 2027. Podtrzymuję ją, ale z zastrzeżeniem, którego wtedy nie postawiłem: ta migracja opłaci się tylko tam, gdzie ktoś zaplanował budżet na utrzymanie frontendu jako oprogramowania, a nie jako dokumentu, który raz się wgrywa i zapomina.

#Podsumowanie

WordPress 7.0 to solidne wydanie, które nie zmienia fundamentów platformy. Astro 7 to raczej porządki pod maską niż nowe funkcje dla użytkownika: kompilator Rust jako domyślny, Vite 8 i ostrzejszy CSP.

Jeśli budujesz sklep online, wybierz WordPressa. Jeśli budujesz stronę firmową, blog albo landing page z naciskiem na wydajność i SEO, wybierz Astro 7 z Cloudflare. Jeśli budujesz jedno i drugie, rozważ hybrydę.

A jeśli nie masz pewności, napisz do mnie. Jeśli Astro jest właściwym wyborem dla twojego projektu, więcej znajdziesz na stronie programista Astro.

Mariusz Szatkowski, programista WordPress i Astro. Organizator WordCamp Gdynia, kontrybutor WordPress Core. Buduje serwisy na obu platformach dla klientów w Polsce i Europie.