Ten tekst porównuje pełny koszt posiadania klasycznego WordPressa z architekturą Astro + Cloudflare. Chodzi o serwisy firmowe, landing page'e, blogi eksperckie i strony ofertowe, nie o duże sklepy ani systemy z intensywną logiką aplikacyjną.
Dlaczego WordPress wygląda taniej niż jest
WordPress wygrywa prostotą startu. Instalacja, motyw, kilka wtyczek — strona działa. Problem zaczyna się po kilku miesiącach, gdy projekt przestaje być stroną i staje się małym systemem utrzymaniowym.
Pełny rachunek TCO, czyli Total Cost of Ownership, to całkowity koszt posiadania strony przez kilka lat — hosting, utrzymanie, licencje, bezpieczeństwo — a nie sama cena budowy. obejmuje:
- hosting PHP/MySQL albo VPS z zarządzaniem serwerem,
- płatne wtyczki do SEO, formularzy, cache, backupów i bezpieczeństwa,
- aktualizacje rdzenia, motywów i pluginów — z ryzykiem regresji po każdej,
- testy po aktualizacjach, bo konflikt wersji potrafi zepsuć formularz,
- backupy, monitoring i czas reakcji na incydenty,
- czas na optymalizację wydajności po każdej większej zmianie.
Co zmienia Astro + Cloudflare
Astro generuje strony treściowe tak, żeby domyślnie wysyłać jak najmniej JavaScriptu do przeglądarki. Interaktywność dodajesz jako wyspy tylko tam, gdzie jest potrzebna: formularz, kalkulator, slider, filtr albo komponent z danymi.
Dla prostego, statycznego Astro Cloudflare Pages nadal jest tanim sposobem serwowania gotowych plików z globalnej sieci CDN, czyli Content Delivery Network, to rozproszona sieć serwerów dostarczająca zasoby z węzła najbliższego użytkownikowi; CDN do obrazów dodatkowo transformuje je w locie.. Według dokumentacji Cloudflare statyczne requesty są darmowe i nielimitowane, a free plan Pages obejmuje m.in. 500 buildów miesięcznie oraz limit 20 000 plików na projekt.
Druga ścieżka to Cloudflare Workers to edge runtime Cloudflare, w którym kod działa blisko użytkownika i ma dostęp do usług platformy przez bindings.. Aktualna dokumentacja Astro wskazuje Workers jako rekomendowany kierunek dla nowych projektów na Cloudflare, szczególnie gdy pojawia się On-demand rendering to generowanie HTML na serwerze przy żądaniu, zamiast podczas builda — potrzebne dla treści dynamicznej i personalizacji., Server Islands, Actions, Sessions albo inne funkcje server-side. Wtedy statyczne assety nadal mogą być darmowe, ale funkcje i requesty dynamiczne rozliczasz według limitów Workers.
- buildów miesięcznie w darmowym planie Cloudflare Pages
- 500
- plików na projekt w darmowym planie Pages
- 20 000
- requestów Workers dziennie w darmowym planie
- 100 000
Porównanie kosztów na 3 lata
Poniższa tabela nie jest cennikiem, tylko modelem decyzyjnym. W konkretnym projekcie liczby zależą od hostingu, liczby wtyczek, wymagań bezpieczeństwa i tego, kto utrzymuje stronę.
| Obszar | Klasyczny WordPress | Astro + Cloudflare |
|---|---|---|
| Hosting | stały koszt PHP/MySQL lub VPS | Pages dla statycznych stron albo Workers dla nowych wdrożeń z logiką server-side |
| Wtyczki | częste licencje roczne | zwykle brak odpowiednika w runtime |
| Bezpieczeństwo | panel, pluginy, motyw, backupy | mniejsza powierzchnia ataku przy statycznym buildzie |
| Maintenance | cykliczne aktualizacje i testy | głównie aktualizacje zależności projektu |
| Skalowanie | zależne od serwera, cache i bazy | statyczne pliki z CDN, a funkcje dynamiczne na Workers |
Wniosek jest prosty: im bardziej strona jest treściowa, tym mocniej WordPress płaci za funkcje, których nie używa. Astro odwraca model: statyczna treść jest tania i szybka, a dynamiczne fragmenty dopinasz świadomie.
Bezpieczeństwo: oszczędność, której nie widać od razu
Dane z raportu Patchstack 2026 są jednoznaczne: 11 334 nowe podatności w ekosystemie WordPress w 2025 roku. 91% dotyczyło wtyczek, 9% motywów, tylko 6 zgłoszeń — samego rdzenia. To nie znaczy, że każdy WordPress jest niebezpieczny. Znaczy, że każda dodatkowa wtyczka to element utrzymania i wektor ryzyka.
Astro nie rozwiązuje wszystkich problemów bezpieczeństwa — nadal możesz mieć formularze, integracje, CMS, funkcje edge. Eliminuje jednak całą kategorię ataków typowych dla publicznego panelu WordPress, PHP i podatnych pluginów.
Najtańsza infrastruktura to ta, której nie musisz łatać w niedzielę wieczorem.
Kiedy migracja zaczyna się zwracać
Migracja ma sens, gdy suma obecnych kosztów przez kolejne 2-3 lata jest większa niż koszt przebudowy. Do rachunku wpisz nie tylko hosting, ale też czas:
- ile kosztuje roczna obsługa techniczna WordPressa,
- ile razy w roku aktualizacje powodują regresje,
- ile wydajesz na wtyczki i narzędzia security,
- ile kosztuje wolniejsza strona w konwersji,
- czy zespół naprawdę potrzebuje klasycznego edytora WordPressa.
Jeśli prosty serwis firmowy kosztuje kilka tysięcy złotych rocznie w utrzymaniu, a ma działać przez pięć lat, migracja na Astro może zwrócić się szybciej niż wynika z samego hostingu. Szczególnie wtedy, gdy równocześnie poprawiasz Core Web Vitals i konwersję. Przy statycznym serwisie koszt Cloudflare może być symboliczny, ale przy formularzach, personalizacji, SSR lub integracjach trzeba doliczyć Workers, storage, zewnętrzny CMS i obsługę wdrożenia.
Kiedy nie migrować na Astro
Nie każdy WordPress powinien zostać przepisany. Astro nie będzie najlepszym wyborem, gdy:
- redakcja potrzebuje klasycznego panelu i nie zaakceptuje Headless CMS oddziela backend treści (panel, baza, API) od frontendu (warstwy prezentacji), który budujesz osobno w dowolnej technologii.,
- sklep korzysta z rozbudowanego WooCommerce, stanów magazynowych i promocji,
- serwis ma wiele funkcji aplikacyjnych wymagających logowania i stanu,
- strona ma zostać wyłączona za kilka miesięcy,
- obecny WordPress jest szybki, bezpieczny i tani w utrzymaniu.
W takich przypadkach lepszy może być headless WordPress, Shopify, Next.js albo po prostu porządny audyt obecnego WordPressa bez pełnej migracji.
