WordPress vs Next.js: co wybrać na stronę firmową
Piotr Koson23.08.202613 minW 2025 roku w ekosystemie WordPressa zgłoszono 11 334 nowe podatności, 91 procent z nich we wtyczkach, a Core Web Vitals zdaje około 49 procent stron na tym systemie. Porównanie obu stosów punkt po punkcie: bezpieczeństwo, szybkość, koszt przez pięć lat i cztery sytuacje, w których WordPress nadal wygrywa.
WordPress i Next.js rozwiązują ten sam problem na dwa różne sposoby: WordPress składa stronę od nowa przy każdym wejściu, Next.js oddaje plik przygotowany wcześniej. Z tej jednej różnicy biorą się wszystkie pozostałe. W 2025 roku w ekosystemie WordPressa zgłoszono 11 334 nowe podatności, z czego 91 procent we wtyczkach, a Core Web Vitals zdaje około 49 procent stron na tym systemie, najmniej ze wszystkich porównywanych platform. Poniżej pełne porównanie: bezpieczeństwo, szybkość, koszt przez pięć lat i cztery sytuacje, w których i tak wybralibyśmy WordPressa.
Czym różni się WordPress od Next.js?
WordPress to system zarządzania treścią napisany w PHP, który przy każdym żądaniu uruchamia kod, odpytuje bazę danych i składa z tego HTML. Next.js to framework, w którym strony można wygenerować raz, przy budowie, i serwować jako gotowe pliki z sieci CDN. Pierwszy jest aplikacją działającą na Twoim serwerze, drugi w typowym zastosowaniu firmowym jest zestawem plików.
| WordPress | Next.js ze statycznym renderowaniem | |
|---|---|---|
| Co dzieje się przy wejściu na stronę | serwer uruchamia PHP, odpytuje bazę i wykonuje kod wszystkich aktywnych wtyczek | CDN oddaje gotowy plik HTML z serwera najbliższego użytkownikowi |
| Kod firm trzecich | motyw plus wtyczki, każda od innego autora i z własnym cyklem wydawniczym | biblioteki wybrane przy wdrożeniu i zamrożone do następnej budowy |
| Aktualizacje | rdzeń, motyw i każda wtyczka osobno, w praktyce co tydzień | zależności aktualizuje wykonawca, strona nie zmienia się sama |
| Panel do treści | wbudowany i bardzo rozbudowany | panel przygotowany pod konkretną stronę, zakres ustalany przy wdrożeniu |
| Powierzchnia ataku | interpreter PHP, baza danych i panel logowania dostępne z internetu | w warstwie publicznej nie ma ani PHP, ani bazy |
| Ekosystem | około 41 procent wszystkich stron w sieci, ogromna baza wtyczek | mniejszy, praktycznie zawsze wymaga programisty |
Ta tabela nie mówi jeszcze, co wybrać. Mówi, gdzie szukać różnic: wszystko poniżej jest konsekwencją pierwszego wiersza.
Dlaczego strony na WordPressie tak często padają ofiarą włamań?
Bo atakuje się nie WordPressa, tylko wtyczki. Według raportu State of WordPress Security in 2026 firmy Patchstack w 2025 roku w całym ekosystemie zgłoszono 11 334 nowe podatności, o 42 procent więcej niż rok wcześniej. 91 procent z nich znaleziono we wtyczkach, 9 procent w motywach, a w rdzeniu WordPressa sześć. Sześć, nie sześćset.
To jest najważniejsza liczba w całym tym tekście, bo odwraca popularny zarzut. Rdzeń WordPressa jest pilnowany przez duży zespół i trzyma poziom. Ryzyko wnosi to, co się do niego dokłada, a dokłada się zawsze, bo bez wtyczek WordPress nie robi połowy rzeczy, których oczekuje firma.
| Co pokazał raport za 2025 rok | Liczba |
|---|---|
| Nowe podatności w ekosystemie | 11 334, wzrost o 42 procent rok do roku |
| Udział wtyczek | 91 procent |
| Udział motywów | 9 procent |
| Podatności w rdzeniu WordPressa | 6 |
| Podatności o wysokim stopniu zagrożenia | 1966, czyli 17 procent, więcej niż przez dwa poprzednie lata razem |
| Podatności bez łatki w dniu ujawnienia | 46 procent |
| Mediana czasu do pierwszego wykorzystania luki | 5 godzin |
Ostatni wiersz jest tym, który przekłada się na praktykę. Jeżeli mediana czasu od ujawnienia do pierwszego ataku liczy się w godzinach, to model "aktualizuję, jak znajdę chwilę" przestaje działać. Skanery chodzą po adresach automatycznie i nie sprawdzają wcześniej, czy Twoja firma jest wystarczająco duża, żeby się nią zająć.
Ile wtyczek ma typowa strona firmowa i co to zmienia?
Policz to na własnym przykładzie. Strona firmowa z ofertą, blogiem i formularzem potrzebuje zwykle osobnego rozwiązania na formularz kontaktowy, na SEO, na cache, na kopie zapasowe, na baner cookies, na galerię, na mapę dojazdu, na integrację z newsletterem i najczęściej na kreator układu podstron. To dziewięć pozycji, zanim ktokolwiek pomyśli o sklepie albo o rezerwacjach.
Każda z nich to osobny kod, osobny autor, osobny cykl wydawniczy i osobna decyzja, czy autor jeszcze ją rozwija. Ryzyko nie sumuje się liniowo z liczbą funkcji, tylko z liczbą niezależnych źródeł kodu, które trzeba śledzić. Dlatego strona z dwudziestoma wtyczkami nie jest dwa razy bardziej narażona niż strona z dziesięcioma. Ma po prostu dwadzieścia niezależnych terminów, których nie można przegapić.
Na stosie, na którym pracujemy, ta sama lista funkcji to kod napisany raz i biblioteki wybrane przy wdrożeniu. Aktualizacja nie jest zdarzeniem, które dzieje się na żywej stronie w środku dnia. Jest budową, która przechodzi testy, a dopiero potem trafia na produkcję.
Czy Next.js jest bezpieczniejszy sam z siebie?
Nie, i warto to powiedzieć wprost. Next.js ma własne podatności, jak każde oprogramowanie, i miewa wśród nich poważne. Żaden framework nie jest tarczą i nikt uczciwy nie sprzeda Ci "strony, której nie da się zhakować".
Różnica jest w dwóch rzeczach, i obie są mierzalne:
- Powierzchnia ataku. Strona renderowana statycznie nie wystawia publicznie interpretera PHP, bazy danych ani panelu logowania pod przewidywalnym adresem. Botów skanujących
/wp-admini/wp-login.phpjest w sieci tyle, że pojawiają się w logach nowej domeny w ciągu doby. Na stronie, która nie ma takiego adresu, po prostu nie mają czego zrobić. - Kto pilnuje terminów. W abonamencie aktualizacje i bezpieczeństwo są świadczone przez cały okres jego trwania, bez dodatkowej opłaty, co zapisano w paragrafie 10 ust. 1 regulaminu. To nie jest przewaga technologii, tylko przewaga umowy. WordPress z tym samym zapisem w umowie o opiekę techniczną ma dokładnie ten sam komfort, za dokładnie tę samą cenę tej opieki.
Uczciwe podsumowanie brzmi więc tak: statyczne renderowanie zmniejsza liczbę rzeczy, które mogą pójść źle, a nie sprowadza jej do zera.
Dlaczego strona na Next.js ładuje się szybciej?
Bo nie musi niczego liczyć w momencie, w którym ktoś na nią wchodzi. Przy wejściu na stronę WordPressa serwer uruchamia PHP, wykonuje kod rdzenia, motywu i wszystkich aktywnych wtyczek, wykonuje zapytania do bazy i dopiero składa HTML. Przy wejściu na stronę renderowaną statycznie serwer CDN oddaje plik, który leżał gotowy.
Ta różnica siada głównie na czasie do pierwszego bajtu, a czas do pierwszego bajtu jest fundamentem LCP, czyli tego, jak szybko pojawia się największy element na ekranie. Nie da się mieć dobrego LCP, jeśli serwer myśli pół sekundy, zanim cokolwiek wyśle.
Druga część różnicy to waga strony. Mediana wagi strony na WordPressie to około 2,63 MB, co w dużej mierze robią kreatory układu, które dokładają własny CSS i JavaScript do każdej podstrony, niezależnie od tego, czy dana podstrona ich potrzebuje.
Kluczowe jest jednak słowo domyślnie. Świeżo postawiony WordPress z popularnym motywem nie jest szybki i nikt tego nie ukrywa: liczy stronę od nowa przy każdym wejściu, ładuje style i skrypty wszystkich aktywnych wtyczek, serwuje zdjęcia w takim formacie, w jakim je wgrałeś. Strona renderowana statycznie startuje z drugiej strony skali: jest szybka od pierwszego dnia, a popsuć ją trzeba dopiero świadomie, wgrywając nieprzygotowane zdjęcia albo dokładając ciężkie skrypty zewnętrzne.
Celowo nie podajemy tu żadnego wyniku PageSpeed z konkretnego projektu, ani naszego, ani cudzego. Pojedynczy wynik zależy od zdjęć, integracji i treści danej strony i nie mówi nic o Twojej. Realizacje, na których pracujemy, są w portfolio.
Czy WordPressa da się przyspieszyć?
Da się, i to skutecznie. Trzeba tylko wiedzieć, czym się za to płaci, bo praktycznie każdy punkt tej listy oznacza dołożenie kolejnej wtyczki.
| Co trzeba zrobić | Czym się to robi w WordPressie | W Next.js ze statycznym renderowaniem |
|---|---|---|
| Przestać liczyć stronę przy każdym wejściu | wtyczka cache generująca statyczny HTML | tak działa domyślnie |
| Zmniejszyć i przekonwertować zdjęcia | wtyczka do optymalizacji obrazów, często z płatnym limitem | wbudowane, obrazy przetwarzane przy budowie |
| Ładować zdjęcia dopiero przy przewijaniu | wtyczka lazy load albo funkcja motywu | wbudowane |
| Skleić i skompresować CSS oraz JavaScript | wtyczka do minifikacji | element procesu budowy |
| Oddawać pliki z serwera bliżej użytkownika | wtyczka CDN plus zewnętrzna usługa | tak działa domyślnie |
| Ograniczyć kod ładowany na podstronach | wtyczka do warunkowego wyłączania skryptów | kod dzielony automatycznie |
Ta tabela zamyka koło otwarte w części o bezpieczeństwie. Żeby przyspieszyć WordPressa, dokładasz od czterech do sześciu kolejnych wtyczek, a każda z nich to znowu kod firmy trzeciej z własnym cyklem aktualizacji, czyli dokładnie ten składnik, który odpowiada za 91 procent podatności w tym ekosystemie. Rozwiązanie problemu wydajności powiększa problem bezpieczeństwa.
Cała ta lista sprowadza się zresztą do jednego zdania: spraw, żeby WordPress przestał liczyć stronę przy każdym wejściu i zaczął oddawać gotowy plik. Czyli do tego, co statyczne renderowanie robi bez wtyczki i bez konfiguracji.
Reszta kosztu jest zwyczajna. Dobry hosting kosztuje więcej niż tani, wtyczkę cache trzeba skonfigurować i pilnować, żeby nie serwowała nieaktualnych treści, a rezygnacja z kreatora układu oznacza, że układ podstrony zmienia programista, nie Ty.
Co Google realnie mierzy w Core Web Vitals?
Trzy wskaźniki z danych prawdziwych użytkowników, a nie z testu laboratoryjnego: LCP (jak szybko pojawia się największy element), INP (jak szybko strona reaguje na kliknięcie) i CLS (jak bardzo układ skacze w trakcie ładowania). Stronę uznaje się za zdaną dopiero wtedy, gdy 75 procent rzeczywistych wizyt mieści się w progu dla każdego z trzech wskaźników osobno.
W danych HTTP Archive i Chrome UX Report ze snapshotu z kwietnia 2026 rozkład wygląda tak:
| Platforma | Odsetek witryn zdających Core Web Vitals |
|---|---|
| Duda | około 85 procent |
| Wix | około 80 procent |
| Shopify | około 79 procent |
| Astro | 67 procent |
| Drupal | około 64 procent |
| Joomla | około 58 procent |
| WordPress | około 49 procent |
Dla porównania: w majowym odczycie CrUX wszystkie witryny w sieci razem zdawały w 55,9 procent. WordPress jest więc poniżej średniej całego internetu i ostatni w tym zestawieniu.
Dwa zastrzeżenia, bez których ta tabela byłaby nieuczciwa. Po pierwsze, to rozkład dla milionów witryn, a nie wyrok na Twoją: dobrze zrobiona strona na WordPressie mieści się w tych 49 procentach, które zdają. Po drugie, raport nie podaje osobnego wiersza dla Next.js, więc nie porównujemy tu liczby do liczby. Astro jest w tabeli najbliższym punktem odniesienia, bo jest generatorem stron statycznych, czyli działa tak jak nasz stos, i wypada o 18 punktów wyżej.
Ile kosztuje wolna strona?
Tyle, ile wynosi różnica w liczbie ludzi, którzy w ogóle doczekali załadowania. Google zmierzyło to na urządzeniach mobilnych: przy wydłużeniu ładowania z 1 do 3 sekund prawdopodobieństwo odrzucenia rośnie o 32 procent, przy przejściu z 1 do 5 sekund o 90 procent, a przy 10 sekundach o 123 procent. To nie jest spadek zainteresowania ofertą. To ludzie, którzy nigdy jej nie zobaczyli.
Druga zakładka przekłada tę krzywą na złotówki dla sklepu z 5000 wizyt miesięcznie i koszykiem 200 zł. Przy jednej sekundzie wychodzi 18 000 zł przychodu miesięcznie, przy pięciu 7200 zł. Różnica to 10 800 zł miesięcznie, czyli 129 600 zł rocznie przy dokładnie tym samym budżecie na reklamę i tym samym ruchu.
Ten sam efekt widać z drugiej strony, przy poprawie. W badaniu Deloitte Milliseconds Make Millions, obejmującym 30 milionów sesji u 37 marek, przyspieszenie strony mobilnej o 0,1 sekundy podniosło konwersję w handlu detalicznym o 8,4 procent, a średnią wartość koszyka o 9,2 procent. W branży turystycznej konwersja wzrosła o 10,1 procent.
Dlatego szybkość nie jest kwestią estetyczną ani punktem w raporcie do odhaczenia. Jest tą samą pozycją w rachunku co koszt pozyskania klienta, tylko po drugiej stronie: reklama sprowadza ruch, a wolna strona wylewa go z powrotem, zanim zdąży cokolwiek sprzedać.
Ile kosztuje utrzymanie WordPressa przez 5 lat?
WordPress jest darmowy, jego utrzymanie nie. Poniższy wykres zestawia pełny koszt strony firmowej na WordPressie z pakietem FIRMA, w którym hosting, certyfikat, kopie, opieka i aktualizacje są w cenie. Przełącznik zmienia jedno założenie: czy opiekę techniczną komuś zlecasz, czy robisz ją sam.
Założenia po stronie WordPressa, wypisane wprost: wdrożenie 3000 zł jednorazowo, czyli najniższa cena z widełek freelancerskich, hosting i odnawialne licencje motywu oraz wtyczek 1100 zł rocznie, opieka techniczna 1800 zł rocznie albo zero, jeśli bierzesz ją na siebie. W czwartym roku po obu stronach wchodzi przeprojektowanie wycenione na 80 procent ceny wdrożenia, czyli 2400 zł, z tą różnicą, że w abonamencie odświeżenie projektu przysługuje bez dopłaty po każdych 36 miesiącach (§10 ust. 4).
| Wariant | Po 1 roku | Po 3 latach | Po 5 latach |
|---|---|---|---|
| WordPress, opieka zlecona | 5900 zł | 11 700 zł | 19 900 zł |
| WordPress, utrzymanie własne | 4100 zł | 6300 zł | 10 900 zł |
| Abonament FIRMA | 1990 zł | 5970 zł | 9950 zł |
Wariant "utrzymanie własne" jest tym, w którym WordPress wypada najlepiej, więc warto go opisać dokładnie. Przez pięć lat bez ani jednego przeprojektowania wychodzi 8500 zł wobec 9950 zł, czyli taniej o 1450 zł. Z przeprojektowaniem w czwartym roku wychodzi 10 900 zł, czyli drożej o 950 zł. Różnica między dwiema zakładkami wykresu, 9000 zł przez pięć lat, to cena Twojego czasu poświęconego na aktualizacje i awarie. Pełne rozbicie samych kosztów utrzymania opisaliśmy w tekście o kosztach utrzymania strony.
Co wchodzi w cenę abonamentu, a co dopłacasz przy WordPressie?
To jest ta część porównania, która najczęściej znika z ofert, bo cena wdrożenia jest widoczna, a pozycje poniżej pojawiają się dopiero w drugim roku.
| Pozycja | WordPress | Abonament FIRMA |
|---|---|---|
| Hosting i certyfikat SSL | osobno, od kilkuset zł rocznie w górę | w cenie (§10 ust. 1) |
| Kopie zapasowe | wtyczka albo usługa hostingu, często płatna | w cenie (§10 ust. 1) |
| Aktualizacje rdzenia, motywu i wtyczek | Twoim czasem albo pakietem opieki | w cenie (§10 ust. 1) |
| Licencje motywu i wtyczek premium | odnawiane co rok, inaczej brak aktualizacji | brak takiej pozycji |
| Zmiany treści | samodzielnie w panelu | samodzielnie w panelu, bez limitu |
| Odświeżenie projektu | wycena od nowa, rynkowo około 80 procent wdrożenia | bez dopłaty po każdych 36 miesiącach (§10 ust. 4) |
| Prawa do kodu | Twoje, o ile umowa tak stanowi | licencja niewyłączna na czas abonamentu (§9) |
Ostatni wiersz jest jedyną pozycją, w której WordPress ma nad abonamentem przewagę bezwarunkową, i nie zamierzamy tego ukrywać. Rozbieramy tę wadę na czynniki pierwsze w tekście o wadach abonamentu, łącznie ze scenariuszem, w którym model abonamentowy przegrywa.
Kto robi aktualizacje i co się dzieje, gdy ich zabraknie?
To jest pytanie, na którym w praktyce rozstrzyga się cały wybór, i większość ofert przechodzi nad nim do porządku dziennego. Warto zadać je wprost każdemu wykonawcy: kto konkretnie, jak często i z jakim czasem reakcji.
Konsekwencje zaniedbania są przewidywalne, bo powtarzają się w tej samej kolejności. Najpierw wstrzyknięte odnośniki w treści, których nie widać w panelu. Potem przekierowania części ruchu z telefonów na obcy adres. Potem ostrzeżenie przeglądarki i wypadnięcie z wyników wyszukiwania. Odzyskanie pozycji po takim wpisie na listy ostrzeżeń trwa tygodnie, a przywrócenie strony z kopii jest najtańszym elementem tego rachunku.
Przy 46 procentach podatności bez łatki w dniu ujawnienia i medianie pięciu godzin do pierwszego wykorzystania luki jedyna sensowna odpowiedź brzmi: robi to ktoś, kto ma to w obowiązku i w umowie. Jeżeli wybierasz WordPressa, dopisz do budżetu pakiet opieki technicznej i traktuj go jak koszt stały, a nie jak dodatek do rozważenia.
Czy na Next.js da się samodzielnie edytować treści?
Tak, i to bez limitu. W cenie każdego pakietu są nieograniczone samodzielne zmiany treści w panelu CMS, bez dopłaty za każdą edycję. Zmienisz teksty, wymienisz zdjęcia, dodasz wpis na blogu i podstronę opartą o istniejący układ.
Jest jednak realna różnica i lepiej znać ją przed decyzją niż po. Panel przygotowujemy pod konkretną stronę, więc nie ma w nim tysiąca opcji, których nigdy nie użyjesz, ale nie ma też możliwości stworzenia od zera nowego typu treści z nową strukturą pól. W WordPressie zrobisz to sam wtyczką, u nas jest to zgłoszenie w ramach opieki.
Dla większości firm ta różnica jest teoretyczna, bo nowy typ treści wymyśla się raz na kilka lat. Jeżeli jednak wiesz, że będziesz często przebudowywać strukturę serwisu własnymi rękami, jest to argument za WordPressem i traktujemy go poważnie.
Jak wygląda SEO i widoczność w AI na obu stosach?
Pod względem klasycznego SEO obie drogi dochodzą do tego samego miejsca. WordPress z porządną wtyczką SEO ustawi tytuły, opisy, mapę witryny i dane strukturalne, i zrobi to dobrze. Nie ma tu przewagi technologicznej, którą warto by sprzedawać.
Różnice są dwie i obie są drugorzędne wobec treści. Pierwsza: dane strukturalne wpinamy w kod strony przy wdrożeniu, jako część szablonu, a nie jako warstwę doklejoną wtyczką, więc nie rozjeżdżają się przy zmianie motywu. Dlaczego to w ogóle ma znaczenie, opisaliśmy w tekście o danych strukturalnych JSON-LD. Druga: szybkość jest jednym z czynników rankingowych, więc to, co napisaliśmy wyżej o Core Web Vitals, wraca tutaj jako mały plus.
W widoczności w modelach językowych, czyli w tym, czy ChatGPT albo Perplexity zacytuje Twoją stronę w odpowiedzi, technologia znaczy jeszcze mniej. Liczy się struktura treści, konkretność i to, czy strona w ogóle oddaje modelowi gotowy tekst, zamiast dorysowywać go JavaScriptem po załadowaniu. Cały mechanizm rozłożyliśmy w tekście o GEO.
Kiedy WordPress jest lepszym wyborem?
W czterech sytuacjach, i w każdej z nich odradzalibyśmy Ci nasz własny stos.
- Masz w zespole kogoś, kto zna WordPressa. Jeśli ktoś u Ciebie robi aktualizacje, pilnuje kopii i umie postawić stronę z kopii po awarii, największy koszt tego ekosystemu już jest pokryty. Wtedy zostaje sama zaleta, czyli ogromna elastyczność.
- Potrzebujesz konkretnej wtyczki, której nie ma nigdzie indziej. Branżowe integracje, systemy rezerwacyjne z długą historią, wtyczki do konkretnych hurtowni. Odtworzenie takiej funkcji od zera jest droższe niż utrzymanie WordPressa przez dekadę.
- Chcesz samodzielnie dokładać nowe typy treści. Bez programisty, bez zgłoszenia, w piątek wieczorem. WordPress to potrafi i to jest jego prawdziwa siła.
- Świadomie chcesz zostać w tym ekosystemie. Bo masz tam procesy, ludzi i przyzwyczajenia. Zrobiliśmy tak w realizacji dla psychologa, na wyraźne życzenie klienta i po omówieniu konsekwencji.
Wspólny mianownik tych czterech punktów: WordPress jest dobrym wyborem wtedy, gdy ktoś świadomie bierze na siebie jego utrzymanie. Zły wybór to nie WordPress. Zły wybór to WordPress bez planu na to, kto go aktualizuje.
Co wybrać na stronę firmową?
Jeśli szukasz strony wizytówkowej albo firmowej z ofertą i blogiem, nie masz w zespole nikogo od technologii i nie chcesz mieć w kalendarzu pozycji "sprawdzić wtyczki", statyczne renderowanie na Next.js wygrywa na wszystkich trzech osiach naraz: mniejsza powierzchnia ataku, lepszy punkt startowy w Core Web Vitals i przewidywalny koszt, w którym opieka nie jest osobną fakturą. Przez pięć lat wychodzi 9950 zł wobec 19 900 zł przy WordPressie z opieką zleconą.
Jeśli natomiast masz kogoś, kto zna WordPressa, albo potrzebujesz wtyczki bez alternatywy, wybierz WordPressa i zbuduj wokół niego proces: pakiet opieki z określonym czasem reakcji, kopie testowane realnym odtworzeniem i lista wtyczek, którą ktoś przegląda raz na kwartał.
Nie zgadujesz, ile to kosztuje po Twojej stronie: policz swój wariant w kalkulatorze i zestaw wynik z tabelami wyżej albo z pełnym cennikiem.


