Przestań myśleć, że WordPress jest tani. Jest drogi — tylko w inny sposób
Na pewno część z Was słyszała to zdanie: "WordPress jest tańszy, Next.js to dla dużych projektów." Bezmyślnie się to powtarza. Developer mówi to klientowi, klient powtarza to następnemu developerowi — i tak w kółko. Problem polega na tym, że to zdanie jest po prostu błędne.
Z mojego doświadczenia w budowaniu stron i aplikacji — w tym pełnoprawnego marketplace'u z własnym systemem rozliczeń na Next.js i Medusa.js jakim jest platforma dla rękodzieła artovnia.com — wiem jedno: WordPress nie jest tani. Jest drogi w inny sposób. Tak, żebyś tego nie zauważył od razu.
Poza tym alternatywy zwykle nie są znane nikomu poza developerami. Klienci nie znają innych stacków. WordPress to coś, o czym słyszała większość: "Chcę stronę — słyszałem, że jak strona, to WordPress.". Taki “snickers” wśród CMS. I tak cykl się powtarza.
Ile naprawdę kosztuje utrzymanie strony na WordPressie?
W wielkim skrócie: WordPress jest darmowy jak drukarka. Urządzenie kosztuje grosze, ale przez następne lata płacisz krocie za tusz.
Hosting — tani hosting to przepis na stronę, która ładuje się 4 sekundy i pada przy 50 jednoczesnych użytkownikach. Żeby działało sensownie, potrzebujesz managed WordPress: Kinsta, WP Engine, Cloudways. Zaczynasz od kilkudziesięciu dolarów miesięcznie — od pierwszego dnia, niezależnie od tego, czy masz ruch, czy nie.
Pluginy premium — SEO plugin, page builder, formularze, cache, backup, security, GDPR... Każdy to kilkadziesiąt dolarów rocznie. Składasz razem stos 8–10 pluginów i nagle płacisz jak za porządny abonament SaaS — za rzeczy, które w nowoczesnym stacku po prostu nie istnieją jako problem.
Dług technologiczny i aktualizacje — WordPress to ruchomy cel. PHP idzie do góry, motyw nie jest kompatybilny, plugin przestał być rozwijany, dwa pluginy zaczynają ze sobą konfliktować. To nie jest scenariusz pesymistyczny — to normalny cykl życia projektu na WP. Ktoś to musi ogarnąć. Ten ktoś to albo Ty, albo developer, któremu płacisz stawkę godzinową za gaszenie pożarów.
Wolna strona WordPress — skąd się bierze problem z wydajnością
Sama architektura PHP + MySQL przy odpowiednim cachowaniu radzi sobie nieźle. Prawdziwy zabójca wydajności to page buildery: Elementor, Divi, WPBakery. Generują gigantyczny DOM, ładują dziesiątki plików CSS i JS, blokują renderowanie. Efekt: LCP powyżej 3 sekund, wysoki TBT, CLS przy ładowaniu fontów. Możesz to naprawić — ale potrzebujesz WP Rocket, konfiguracji CDN, ręcznej optymalizacji i kilku dni roboty. I znowu: ktoś to musi ogarnąć.
Bezpieczeństwo strony WordPress — dlaczego to realny problem
WordPress odpowiada za ponad 40% wszystkich stron na świecie. Co to oznacza? Że jest celem numer jeden dla zautomatyzowanych ataków. Każdy bot skanuje internet pod kątem /wp-admin i /wp-login.php. xmlrpc.php — endpoint domyślnie aktywny — jest regularnie używany do ataków brute-force i DDoS amplification. Wiem bo sam obserwuję to w logach swoich stron i aplikacji choć w większości są na Next.js.
Ale największy problem to wtyczki. W 2024 roku w ekosystemie WordPress znaleziono 7 966 nowych podatności — wzrost o 34% względem roku poprzedniego. 96% z nich to wtyczki. Co trzecia z tych luk pozostała bez łatki w momencie publicznego ujawnienia. 43% było exploitowalnych bez żadnego uwierzytelnienia — atakujący nie potrzebuje hasła, konta, niczego. Wystarczy znać lukę i uruchomić skrypt.
To nie są egzotyczne przypadki. Krytyczne podatności regularnie trafiają w wtyczki z setkami tysięcy aktywnych instalacji — formularze kontaktowe, page buildery, narzędzia do backupu. Rzeczy, które masz na każdej stronie.
I tu jest sedno problemu: nie kontrolujesz tego, kiedy autor wtyczki wyda łatkę — ani czy w ogóle ją wyda. W 2024 roku porzucono 827 wtyczek i motywów. Jeśli jedna z nich jest na Twojej stronie, luka zostaje otwarta na zawsze.
Next.js nie jest magicznie bezpieczny — źle napisany kod to źle napisany kod, niezależnie od technologii. Ale zautomatyzowane ataki, które codziennie skanują internet w poszukiwaniu WordPressów, po prostu nie mają tu czego szukać. Nie ma przewidywalnych endpointów, nie ma ekosystemu wtyczek z niezałatanymi CVE. O tym, jak podchodzić do bezpieczeństwa w Next.js i na co uważać przy developmencie, piszę szczegółowo w tym artykule.
Next.js jako alternatywa dla WordPressa — co zyskujesz i ile to kosztuje
Haczyk polega na tym, że Next.js działa na zupełnie innym modelu kosztowym. Większość ludzi patrzy tylko na koszt wdrożenia — nie na całkowity koszt posiadania.
Hosting za 0 zł — Vercel Hobby plan jest darmowy i wystarczy dla zdecydowanej większości lokalnych biznesów, stron firmowych, portfolio i landing page'ów. Zaczynasz płacić przy skali, której większość małych projektów nigdy nie osiągnie.
CMS za 0 zł — Sanity w darmowym planie obsługuje do 3 użytkowników, nieograniczone dokumenty i 10 GB storage. Startujecie ze stackiem, który kosztuje 0 zł miesięcznie przez długi czas.
Architektura, która ma sens — Next.js generuje strony podczas buildu lub cachuje je na poziomie CDN. Użytkownik dostaje gotowy HTML serwowany z edge node'a najbliższego jego lokalizacji — bez PHP, bez bazy danych, bez generowania strony w locie. TTFB poniżej 100 ms to tu po prostu domyślne zachowanie.
Mniejsza powierzchnia ataku — Nie ma /wp-admin dostępnego dla całego internetu. Nie ma xmlrpc.php. Nie ma ekosystemu pluginów z niezałatanymi podatnościami. Zautomatyzowane ataki skanujące internet w poszukiwaniu WordPressów po prostu nie mają tu czego szukać.
Przewidywalność — zależności aktualizujesz kiedy chcesz i testujesz lokalnie, zanim cokolwiek trafi na produkcję. Nie ma "aktualizacji pluginu, która coś psuje w sobotę przed kampanią".
Koszty nowoczesnej strony szczegółowo opisuję w tym artykule:
Ile kosztuje nowoczesna strona internetowa w 2026 roku?
"Ale klient nie będzie umiał edytować strony"
To najczęstszy argument za WordPressem. I jest słaby.
Nowoczesne headless CMS-y mają interfejsy prostsze od WordPressa, nie trudniejsze. Klient klika, edytuje, publikuje — bez wchodzenia w żaden kod.
Można pójść jeszcze dalej. Budując schematy w Sanity czy Payload, projektujesz panel edycji dokładnie pod potrzeby klienta. Tylko te pola, które faktycznie będzie zmieniał. W dokładnie takiej kolejności. Z takimi nazwami, jakie mają dla niego sens. Bez opcji, które może przypadkowo popsuć.
Sam tak robię — kilka dni pracy przy konfigurowaniu schematów zwraca się w zerowej liczbie telefonów z pytaniem "jak to zmienić". WordPress daje Ci gotowy panel dla wszystkich. Headless CMS daje Ci narzędzie, żeby zbudować panel dla tego konkretnego człowieka.
WordPress vs Next.js — wydajność w liczbach
Dobrze napisana aplikacja Next.js powinna osiągać:
- LCP poniżej 2 s (celuj w 1–1,5 s)
- CLS bliskie 0
- TTFB poniżej 200 ms przy edge deployment
Te liczby mają realne znaczenie. Google używa Core Web Vitals jako sygnału rankingowego. Strona wolna odpada w wynikach wyszukiwania.
Na WordPressie osiągnięcie tych wyników jest możliwe — ale wymaga odpowiedniego cachowania, CDN, optymalizacji obrazków, eliminacji render-blocking scripts i rezygnacji z ciężkich builderów. W praktyce: kilka dni roboty i kilka płatnych narzędzi. Na Next.js większość tych rzeczy wynika z architektury, nie z łatania złych domyślnych ustawień.
Kiedy WordPress uczciwie ma sens
Nie zamierzam wciskać Wam, że WordPress zawsze jest złym wyborem. Ma swoje zastosowania:
- Klient, który od lat siedzi w WP i absolutnie nie chce uczyć się niczego nowego
- Blog z ogromną historią postów już na WordPressie — migracja może kosztować więcej niż jest warta
- Budżet rzędu 500–1000 zł na stronę z gotowym motywem — Elementor zrobi robotę i nikt nie będzie udawać, że to architektura na lata
- Projekt, gdzie klient potrzebuje pełnej samodzielności bez wsparcia technicznego i zna WP od podszewki
Poza tymi przypadkami... Next.js wygrywa.
Na koniec
Następnym razem, kiedy usłyszysz "zróbmy to na WordPressie, bo taniej" — zapytaj: tańsze przez ile czasu? Dla kogo? Czy ktoś policzył całkowity koszt posiadania przez 3 lata?
Stack Next.js + headless CMS: darmowy hosting na start, darmowy CMS na start, panel szyty na miarę, zero pluginów do utrzymywania, zero niespodzianek po aktualizacjach, architektura, która nie wywali się przy większym ruchu.
Koszt to kilka dni solidnego developmentu — zamiast lat abonamentów i gaszenia pożarów.
Customowe nie znaczy drogie. Znaczy zaprojektowane pod Ciebie — zamiast dopasowywania się do ograniczeń narzędzia, które powstało dla wszystkich i dla nikogo konkretnie.
Osobiście preferuję wolność i dedykowane rozwiązania.