Jeśli śledzisz mojego bloga, widziałeś już wpis o naprawianiu WordPressa po nieudanej aktualizacji. To nie przypadek, że akurat ten temat znam dobrze — i akurat dlatego, po latach pracy z tym systemem, świadomie się z niego wycofałem przy nowych projektach. Nie z kaprysu ani mody. Z konkretnych, powtarzających się powodów, które opiszę bez owijania w bawełnę.
Zacznijmy uczciwie: WordPress nie jest “zły”
Zanim ktoś pomyśli, że to tekst hejterski — WordPress napędza ogromną część internetu i dla wielu zastosowań (rozbudowane serwisy z contentem, blogi prowadzone przez wiele osób nietechnicznych, duże redakcje) wciąż ma sens. To nie jest zły system. To po prostu nie jest system pod to, co ja buduję — a moi klienci zwykle potrzebują czegoś innego, niż WordPress oferuje z założenia.
Powód 1: Każda wtyczka to cudzy kod, za który ja biorę odpowiedzialność
Typowa strona WordPress ma 15-30 wtyczek. Każda z nich to kod napisany przez kogoś innego, o nieznanej jakości, aktualizowany (albo nie) w nieznanym tempie, z nieznaną historią luk bezpieczeństwa. Kiedy budujesz stronę na WordPressie, w praktyce podpisujesz się pod jakością pracy dziesiątek anonimowych zespołów, których nigdy nie poznasz. Wolę pisać (albo świadomie dobierać z AI jako asystentem) kod, za który realnie rozumiem każdą linijkę.
Powód 2: Bezpieczeństwo to gra w rosyjską ruletkę z automatycznymi botami
WordPress jest tak popularny, że stał się głównym celem automatycznych ataków skanujących internet w poszukiwaniu nieaktualnych wtyczek. To nie kwestia “czy”, tylko “kiedy” — nieaktualizowana strona prędzej czy później zostanie zeskanowana i, jeśli ma lukę, zaatakowana. Utrzymanie tego wymaga stałej czujności, którą łatwo jest zaniedbać, zwłaszcza u klientów, którzy “nie mają czasu” na regularne aktualizacje.
Powód 3: Wydajność, którą trzeba non-stop naprawiać, zamiast mieć ją od początku
Świeża instalacja WordPressa działa całkiem nieźle. Po dodaniu wtyczki do formularzy, wtyczki do SEO, wtyczki do cache (żeby naprawić spowolnienie od poprzednich wtyczek), buildera stron i systemu rezerwacji — strona zaczyna przypominać samochód z pięcioma dodatkowymi silnikami przyczepionymi z boku, żeby jechał szybciej. Da się to zoptymalizować, ale to ciągła walka pod prąd, zamiast budować coś lekkiego od pierwszej linijki kodu.
Powód 4: Elastyczność, która w praktyce jest iluzoryczna
WordPress reklamuje się jako “zrobisz wszystko” — i technicznie to prawda, ale często oznacza to sklejanie ze sobą wtyczek, które nie zostały zaprojektowane, żeby ze sobą współpracować. Coś, co w moim podejściu (Astro, Next.js, dedykowany kod) jest jedną, spójną decyzją architektoniczną, na WordPressie bywa kompromisem między trzema wtyczkami, z których każda robi 80% tego, czego potrzebujesz, a resztę trzeba dopisywać ręcznie.
Więc dlaczego czasem jednak dotykam WordPressa?
Bo rzeczywistość biznesowa nie zawsze pyta o moje preferencje. Jeśli klient ma już działającą stronę na WordPressie, jest z niej zadowolony pod względem funkcji, a problem jest konkretny (strona nie działa po aktualizacji, jest wolna, ktoś ją zhakował) — naprawiam to bez marudzenia. Nie każda sytuacja to okazja do przekonywania kogoś, żeby przebudował całą stronę od zera z innym stackiem, zwłaszcza jeśli to, co ma, wystarczająco dobrze mu służy.
Granica jest prosta: naprawiam istniejące WordPressy, ale nowe projekty buduję inaczej. To nie jest niekonsekwencja — to po prostu dopasowanie narzędzia do sytuacji, a nie do własnych sympatii.
Co robię zamiast tego
Nowe projekty budujesz u mnie w oparciu o nowoczesne, lekkie technologie (Astro, Next.js, dedykowany backend), bez warstwy dziesiątek cudzych wtyczek między Twoją stroną a serwerem. Efekt: strona, która ładuje się szybciej, ma mniejszą powierzchnię ataku, i której każdy element rozumiem, bo sam (lub z pomocą AI pod moją kontrolą) go zbudowałem — a nie zainstalowałem od nieznanego autora z internetu.
Kluczowa różnica filozoficzna: takie strony domyślnie nie wożą żadnego zbędnego JavaScriptu (zero JS z założenia). Interakcje — menu, akordeon, formularz — dokładasz pojedynczo, tam gdzie faktycznie są potrzebne, zamiast ładować globalny silnik na każdej podstronie. To dokładna odwrotność modelu WordPressa, gdzie każda wtyczka dokłada własny kod, który potem trzeba sprzątać kolejnymi wtyczkami do optymalizacji.
Do tego spójny system projektowania (design system): jedna paleta kolorów, dwa fonty z jasno przypisanymi rolami, rytm odstępów — całość domyślnie wygląda na przemyślaną, nawet gdy wymienisz połowę treści. To seria drobnych, trzymanych w ryzach ograniczeń, które sprawiają, że strona wygląda na zaprojektowaną — zamiast zlepić kilkadziesiąt wtyczek i mieć nadzieję.
Masz stronę na WordPressie i zastanawiasz się, czy warto ją przebudować, czy raczej naprawić to, co jest? Napisz, co się dzieje z Twoją stroną — powiem szczerze, która droga ma dla Ciebie sens.