Autor: Urszula Ćwiklińska
To trzeci artykuł z serii poświęconej stronom internetowym. Tym razem przyglądam się narzędziom, których używamy do ich tworzenia, i temu, czy wybór technologii rzeczywiście przesądza o jakości strony.

„Zlecę zrobienie strony, bez użycia buildera – tylko Gutenberg”.

Takie zapytania coraz częściej widzę na portalach ze zleceniami. Czasem w wymaganiach wprost napisane jest: bez Elementora, bez Avady, bez page builderów. Ma być Gutenberg, bo jest lekki, szybki i „czysty”.

Tylko czy wybór konkretnego narzędzia naprawdę przesądza o jakości strony? Mam wrażenie, że łatwo przyklejamy technologiom konkretne łatki. Gutenberg jest lekki i szybki, buildery ciężkie, custom zawsze lepszy, a AI za chwilę ma sprawić, że właściwie nie będziemy potrzebować żadnego z nich.

Moim zdaniem rzeczywistość jest trochę bardziej skomplikowana, a samo stwierdzenie, że Gutenberg jest lekki, to trochę za mało. Najczęściej klient potrzebuje formularza kontaktowego, banera cookies, czasem jakiegoś pop-upu, slidera, bardziej rozbudowanego menu, niestandardowych pól, filtrowania czy dynamicznych treści, a tego sam Gutenberg nie zapewnia. Do tego dochodzi WooCommerce, bo klient chciałby na przykład sprzedawać e-booki.

I tak do „lekkiego Gutenberga” zaczynamy dokładać kolejne wtyczki albo własny kod, bo sam Gutenberg zwyczajnie nie wystarczy do zrealizowania wszystkich potrzeb klienta.

Z tym własnym „customowym” kodem bywa zresztą jeszcze ciekawiej. Mam klientkę, której strona została zbudowana kilka lat temu właśnie na Gutenbergu, a potrzebne dodatkowe funkcjonalności napisano w czystym PHP. Do pewnego czasu wszystko działało. Problem pojawił się, kiedy klientka zaczęła dostawać setki wiadomości od botów, ponieważ żaden z formularzy nie był zabezpieczony przed spamem.

Teraz pojawił się kolejny problem. Część wykorzystanych w tym rozwiązaniu funkcji jest już przestarzała, a strona musi zostać dostosowana do nowszej wersji PHP. W przeciwnym razie klientka będzie musiała dodatkowo płacić za możliwość korzystania ze starszej wersji języka.

Czy powinniśmy kogoś za to obwiniać? Moim zdaniem nie. Kod się starzeje, PHP się rozwija, WordPress się zmienia. To naturalny proces. Własny kod również wymaga utrzymania, aktualizacji i czasem dostosowania do zmieniającego się środowiska. „Custom” nie oznacza przecież, że raz napisane rozwiązanie będzie działało bez końca – tak samo jak sam „Gutenberg” wcale nie gwarantuje, że strona będzie lekka i czysta.

Każde rozwiązanie ma swój koszt. Czasem płacimy za niego na początku, a czasem kilka lat później, przy pierwszej większej aktualizacji.

Nie taki builder straszny, jak go rysują…

Page buildery w wielu dyskusjach o WordPressie obrywają właściwie na każdym kroku. Są ciężkie, generują za dużo kodu, ładują niepotrzebne skrypty, spowalniają stronę. I część tych zarzutów jest jak najbardziej uzasadniona. Rozbudowany builder zawsze będzie miał większy narzut niż czysty Gutenberg, a jeśli zaczniemy korzystać ze wszystkich dostępnych efektów tylko dlatego, że możemy, bardzo szybko da się zbudować stronę, która będzie ciężka i powolna.

Tylko znowu – to nie jest cała historia.

Pracuję głównie z Avadą, która jest chyba najlepszym przykładem rozwiązania określanego mianem „kombajnu”. I nie ma się co oszukiwać – właśnie tym jest. A ja właśnie dlatego jej używam. W jednym środowisku mam formularze, popupy, off-canvas, elementy dynamiczne, własne layouty dla stron, wpisów czy produktów, integrację z WooCommerce i sporą liczbę elementów, do których przy innym podejściu musiałabym szukać kolejnych 20 wtyczek.

Nie oznacza to oczywiście, że strona oparta na Avadzie nie potrzebuje żadnych dodatkowych rozwiązań. Potrzebuje – chociażby wtedy, kiedy chcę tworzyć niestandardowe typy wpisów czy bardziej rozbudowane pola. Różnica polega na tym, że nie muszę szukać osobnej wtyczki do każdej podstawowej funkcjonalności. Formularz kontaktowy? Mam go już w Avadzie. Popup? Też. Chcę stworzyć własny layout produktu albo wpisu i wykorzystać w nim dynamiczne dane? Zgadnijcie – też mam to pod ręką.

I właśnie w tym miejscu „kombajn” przestaje być dla mnie wadą. Wolę jedno większe narzędzie, które znam i którego sposób działania rozumiem, niż zestaw kilkunastu mniejszych rozwiązań od różnych producentów, które trzeba ze sobą połączyć i później utrzymywać. Avada jest regularnie rozwijana i aktualizowana, a po odpowiednim przeszkoleniu klient jest w stanie samodzielnie wprowadzać wiele zmian na stronie. Nie musi angażować mnie za każdym razem, kiedy chce zmienić treść, dodać nową sekcję czy przebudować fragment podstrony.

A może WordPress tylko na zapleczu?

Do tego wszystkiego dochodzi jeszcze jeden trend, który wraz z rozwojem narzędzi AI widzę coraz częściej. WordPress zostaje jako backend – trzymamy w nim produkty czy wpisy – ale warstwa, którą widzi użytkownik, jest budowana osobno. Frontend może być napisany w React, Next.js, Astro czy Svelte i pobierać dane z WordPressa przez API.

I żeby była jasność: headless WordPress nie jest żadnym wynalazkiem AI. Takie rozwiązania wykorzystywane były już wcześniej i w odpowiednich projektach mają sporo sensu. AI sprawiło jednak, że dzisiaj można wygenerować efektowny frontend naprawdę szybko, nawet jeśli jeszcze chwilę wcześniej nigdy czegoś takiego się nie tworzyło.

I tutaj zadam pytanie: co będzie dalej?

Bo klient nadal ma WordPressa. Loguje się do panelu, zmienia tytuł wpisu, opis usługi czy zdjęcie i wszystko jest w porządku, dopóki osoba, która tworzyła stronę, przewidziała wcześniej, że te elementy mają być edytowalne. Gorzej, kiedy za pół roku klient stwierdzi, że chce osadzić nową sekcję na stronie głównej, zmienić jej układ, dodać kolejny rodzaj treści albo przebudować formularz. Czy będzie w stanie zrobić to sam?

W klasycznym WordPressie z Gutenbergiem czy builderem część takich zmian klient może wykonać sam. W rozwiązaniu headless bardzo szybko wkraczamy już w kod frontendu. A przeciętny właściciel firmy raczej nie otworzy sobie projektu w Next.js, żeby przesunąć sekcję albo dodać nowy komponent.

Załóżmy jednak, że będzie chciał zrobić to sam. Musi wiedzieć, gdzie znajduje się kod jego strony, jak uruchomić projekt i gdzie wprowadzić odpowiednią zmianę. A samo zapisanie pliku nie wystarczy – nową wersję trzeba jeszcze wdrożyć. Być może zrobić commit i push do repozytorium, po którym uruchomi się – lub nie – automatyczny deploy. A jeśli deploy się nie powiedzie, trzeba jeszcze ustalić, dlaczego build nagle się wysypał.

Dla developera to codzienność. Dla właściciela salonu kosmetycznego, firmy serwisowej czy kancelarii – niekoniecznie.

I teraz zadajmy sobie proste pytanie: czy klient, któremu oddajemy taką stronę, będzie umiał to zrobić? Jeśli nie, w praktyce staje się zależny od twórcy serwisu. Nie ma w tym nic złego, jeżeli wie o tym od początku i świadomie wybiera taki model. Gorzej, jeżeli dowiaduje się o tym dopiero przy pierwszej większej zmianie.

Podobnie patrzę na pojawiające się coraz częściej oferty stron tworzonych za pomocą AI. Dzisiaj możemy wygenerować naprawdę efektowną stronę za pomocą Claude’a, ChatGPT czy innych narzędzi, wdrożyć ją i powiedzieć klientowi: gotowe. I rzeczywiście – strona jest gotowa. Tylko znowu pojawia się pytanie: co dalej?

Mam klientkę, która ostatnio zainteresowała się Lovable. Ktoś pokazał jej możliwości tego narzędzia i była nimi zachwycona. Trudno się dziwić – opisujesz, co chcesz uzyskać, po chwili dostajesz działającą stronę, a kolejne zmiany wprowadzasz za pomocą promptów. Szybko, efektownie i bez konieczności pisania kodu.

Tylko że klientka nie wiedziała już na przykład, że jeśli chce zostać w ekosystemie Lovable i podpiąć własną domenę, potrzebuje płatnego planu. Oczywiście może zsynchronizować kod z GitHubem i wdrożyć go gdzie indziej. Tylko wtedy znowu pojawiają się pytania: gdzie? Jak? Kto zrobi deploy? Kto zajmie się tym za pół roku?

I właśnie dlatego trochę niepokoją mnie pojawiające się oferty typu „strona za 500 zł z AI”. Nie dlatego, że za 500 zł nie da się dzisiaj stworzyć strony. Da się. AI bardzo mocno skróciło czas potrzebny na jej przygotowanie, ale nasuwa mi się pytanie: co obejmuje te 500 zł?

Czy wykonawca po prostu wygeneruje stronę, podłączy domenę i przekaże dostęp? Czy klient wie, jakie koszty będzie ponosił później? Czy wie, co będzie mógł zmienić samodzielnie? Czy wie, co zrobić, kiedy będzie chciał zrezygnować z używanej platformy? Czy dostanie kod? Czy będzie wiedział, co z nim zrobić?

Bo „wygeneruję Ci stronę” i „zbuduję Ci stronę, którą będziesz mógł przez następne lata normalnie wykorzystywać i rozwijać” to jednak dwie różne usługi.

I żeby nie było wątpliwości – nie mam nic przeciwko AI w tworzeniu stron. Wręcz przeciwnie. Sama z niego korzystam. Pozwala mi szybciej szukać rozwiązań, analizować problemy czy przygotowywać elementy, nad którymi wcześniej spędzałam znacznie więcej czasu.

Tylko AI, podobnie jak Gutenberg, page builder czy własny kod, nadal jest narzędziem.

A dobre narzędzie w rękach osoby, która wie, jak go używać, potrafi zrobić świetną robotę.

Więc w czym właściwie budować strony?

Po tym wszystkim można dojść do wniosku, że nie ma dobrego rozwiązania. Gutenberg wymaga dodatkowych wtyczek. Buildery mają swój narzut. Własny kod trzeba utrzymywać. Headless komplikuje późniejszą edycję, a przy narzędziach AI trzeba wiedzieć, co właściwie dostajemy.

A ja nadal uważam, że zamiast zaczynać projekt od wyboru technologii, powinniśmy zacząć od rozmowy z klientem i zrozumienia, czego naprawdę potrzebuje, a dopiero później dobierać narzędzia i technologie. Bo czasem najlepszym wyborem będzie Gutenberg, czasem page builder, a czasem własny kod, headless czy rozwiązanie stworzone z pomocą AI. I żadne z tych rozwiązań nie jest z definicji lepsze czy gorsze od pozostałych.

A jeśli jesteś po drugiej stronie i właśnie szukasz wykonawcy strony, nie patrz tylko na cenę jej stworzenia. Zapytaj też, co będziesz mógł zrobić sam, ile będzie kosztowało jej późniejsze utrzymanie i co się stanie, kiedy za rok będziesz chciał coś zmienić. Bo najtańsza strona w dniu wdrożenia niekoniecznie będzie najtańszą stroną dwa lata później.