xqxpl
WordPress vs Next.js: co wybrać na stronę firmowąStrony

WordPress vs Next.js: co wybrać na stronę firmową

Piotr KosonPiotr Koson23.08.202613 min

W 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.

Udostępnij:Na X (Twitter)

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.

WordPressNext.js ze statycznym renderowaniem
Co dzieje się przy wejściu na stronęserwer uruchamia PHP, odpytuje bazę i wykonuje kod wszystkich aktywnych wtyczekCDN oddaje gotowy plik HTML z serwera najbliższego użytkownikowi
Kod firm trzecichmotyw plus wtyczki, każda od innego autora i z własnym cyklem wydawniczymbiblioteki wybrane przy wdrożeniu i zamrożone do następnej budowy
Aktualizacjerdzeń, motyw i każda wtyczka osobno, w praktyce co tydzieńzależności aktualizuje wykonawca, strona nie zmienia się sama
Panel do treściwbudowany i bardzo rozbudowanypanel przygotowany pod konkretną stronę, zakres ustalany przy wdrożeniu
Powierzchnia atakuinterpreter PHP, baza danych i panel logowania dostępne z internetuw warstwie publicznej nie ma ani PHP, ani bazy
Ekosystemokoło 41 procent wszystkich stron w sieci, ogromna baza wtyczekmniejszy, 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 rokLiczba
Nowe podatności w ekosystemie11 334, wzrost o 42 procent rok do roku
Udział wtyczek91 procent
Udział motywów9 procent
Podatności w rdzeniu WordPressa6
Podatności o wysokim stopniu zagrożenia1966, czyli 17 procent, więcej niż przez dwa poprzednie lata razem
Podatności bez łatki w dniu ujawnienia46 procent
Mediana czasu do pierwszego wykorzystania luki5 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:

  1. Powierzchnia ataku. Strona renderowana statycznie nie wystawia publicznie interpretera PHP, bazy danych ani panelu logowania pod przewidywalnym adresem. Botów skanujących /wp-admin i /wp-login.php jest 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ć.
  2. 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 WordPressieW Next.js ze statycznym renderowaniem
Przestać liczyć stronę przy każdym wejściuwtyczka cache generująca statyczny HTMLtak działa domyślnie
Zmniejszyć i przekonwertować zdjęciawtyczka do optymalizacji obrazów, często z płatnym limitemwbudowane, obrazy przetwarzane przy budowie
Ładować zdjęcia dopiero przy przewijaniuwtyczka lazy load albo funkcja motywuwbudowane
Skleić i skompresować CSS oraz JavaScriptwtyczka do minifikacjielement procesu budowy
Oddawać pliki z serwera bliżej użytkownikawtyczka CDN plus zewnętrzna usługatak działa domyślnie
Ograniczyć kod ładowany na podstronachwtyczka do warunkowego wyłączania skryptówkod 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:

PlatformaOdsetek witryn zdających Core Web Vitals
Dudaokoło 85 procent
Wixokoło 80 procent
Shopifyokoło 79 procent
Astro67 procent
Drupalokoło 64 procent
Joomlaokoło 58 procent
WordPressokoł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).

WariantPo 1 rokuPo 3 latachPo 5 latach
WordPress, opieka zlecona5900 zł11 700 zł19 900 zł
WordPress, utrzymanie własne4100 zł6300 zł10 900 zł
Abonament FIRMA1990 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.

PozycjaWordPressAbonament FIRMA
Hosting i certyfikat SSLosobno, od kilkuset zł rocznie w góręw cenie (§10 ust. 1)
Kopie zapasowewtyczka albo usługa hostingu, często płatnaw cenie (§10 ust. 1)
Aktualizacje rdzenia, motywu i wtyczekTwoim czasem albo pakietem opiekiw cenie (§10 ust. 1)
Licencje motywu i wtyczek premiumodnawiane co rok, inaczej brak aktualizacjibrak takiej pozycji
Zmiany treścisamodzielnie w panelusamodzielnie w panelu, bez limitu
Odświeżenie projektuwycena od nowa, rynkowo około 80 procent wdrożeniabez dopłaty po każdych 36 miesiącach (§10 ust. 4)
Prawa do koduTwoje, o ile umowa tak stanowilicencja 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.

  1. 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ść.
  2. 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ę.
  3. 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.
  4. Ś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.

← Wszystkie artykułyUdostępnij
FAQ

Najczęstsze pytania

Czy WordPress jest bezpieczny?
Rdzeń WordPressa jest bezpieczny: w 2025 roku zgłoszono w nim sześć podatności. Problemem jest to, co się do niego dokłada. W całym ekosystemie znaleziono w tym samym roku 11 334 nowe podatności, z czego 91 procent we wtyczkach i 9 procent w motywach, a 46 procent z nich nie miało łatki w dniu ujawnienia. Bezpieczeństwo strony na WordPressie sprowadza się więc do jednego pytania: kto i jak szybko aktualizuje wtyczki.
Czy strona na Next.js jest szybsza od WordPressa?
Zwykle tak, ale nie dlatego, że Next.js jest szybszy jako framework. Powód jest strukturalny: strona renderowana statycznie oddaje gotowy plik HTML z CDN, a WordPress przy każdym wejściu uruchamia PHP, odpytuje bazę i wykonuje kod wszystkich aktywnych wtyczek. W danych HTTP Archive z kwietnia 2026 Core Web Vitals zdaje około 49 procent stron na WordPressie, przy 55,9 procent dla wszystkich witryn w sieci. To rozkład dla milionów stron, nie wyrok na Twoją.
Ile kosztuje utrzymanie strony na WordPressie przez 5 lat?
Przy wdrożeniu za 3000 zł, hostingu i licencjach za 1100 zł rocznie oraz opiece technicznej za 1800 zł rocznie wychodzi 17 500 zł przez pięć lat, a z przeprojektowaniem w czwartym roku 19 900 zł. Jeśli aktualizacje robisz sam, odpada 1800 zł rocznie i zostaje 8500 zł bez przeprojektowania albo 10 900 zł z przeprojektowaniem. Pakiet FIRMA to 1990 zł rocznie, czyli 9950 zł przez pięć lat, z hostingiem, opieką i odświeżeniem projektu w cenie.
Czy na Next.js mogę sam edytować treści?
Tak. W cenie każdego pakietu jest panel CMS i nieograniczone samodzielne zmiany treści, bez dopłaty za każdą edycję. Różnica wobec WordPressa jest realna: zakres panelu ustalamy przy wdrożeniu, więc dołożysz w nim tekst, zdjęcie, wpis i podstronę z istniejącego szablonu, ale nie stworzysz sam nowego typu treści z nową strukturą pól. To wymaga zgłoszenia w ramach opieki.
Kiedy WordPress jest lepszym wyborem niż Next.js?
W czterech sytuacjach. Gdy masz w zespole kogoś, kto zna WordPressa i bierze utrzymanie na siebie. Gdy potrzebujesz konkretnej wtyczki branżowej, której nie ma poza tym ekosystemem. Gdy chcesz samodzielnie dokładać nowe typy treści bez udziału programisty. Gdy świadomie chcesz zostać w tym ekosystemie, bo tam masz procesy i ludzi. Robimy strony na WordPressie w takich przypadkach.
Czy Next.js nie ma własnych podatności?
Ma, jak każde oprogramowanie. Różnica nie polega na tym, że jeden stos jest szczelny, a drugi dziurawy, tylko na wielkości powierzchni ataku i na tym, kto pilnuje aktualizacji. Strona renderowana statycznie nie wystawia publicznie ani interpretera PHP, ani bazy danych, ani panelu logowania pod przewidywalnym adresem. Liczba niezależnych źródeł kodu, które trzeba śledzić, jest przy tym mniejsza o kilkanaście wtyczek.

Powiązane artykuły