Headless WordPress i Next.js - kiedy ma sens, a kiedy to overengineering
"Zróbmy to headless" - to zdanie coraz częściej pada na spotkaniach o nowej stronie lub sklepie. Brzmi nowocześnie, kojarzy się z szybkością i z technologią, której używają duże firmy. Mało kto dodaje, ile to kosztuje i co się przy okazji traci.
Wdrożyłem sklep WooCommerce w układzie headless i napiszę wprost: w tamtym przypadku nie było warto. Poniżej wyjaśniam, czym ten układ jest, co realnie daje, gdzie robi się drogo i jak sprawdzić, czy Twój projekt w ogóle go potrzebuje. Nie jestem jego przeciwnikiem. Buduję też aplikacje w Next.js i React, więc wiem, kiedy to rozwiązanie jest właściwe. Z mojego doświadczenia jest to rzadziej, niż sugerują oferty.
Krótka odpowiedź
Headless WordPress to układ, w którym WordPress służy tylko do wpisywania i przechowywania treści, a wygląd strony robi osobna aplikacja, na przykład w Next.js. Daje dowolność interfejsu i pozwala wykorzystać te same treści w kilku miejscach. Kosztuje za to więcej, bo zamiast jednego systemu masz dwa, a część wtyczek i wygody edycji przestaje działać.
Dla większości stron firmowych, blogów i sklepów headless nie jest potrzebny. Szybkość i SEO da się uzyskać w zwykłym WordPressie. Na końcu jest sześć pytań, które pozwalają to ocenić, oraz krótka uwaga o tym, jak AI zmieniło koszt budowy takich rozwiązań.
Czym jest headless WordPress (bez żargonu)
Tradycyjny WordPress to restauracja, w której kuchnia i sala są jednym pomieszczeniem. Ten sam system przechowuje treści i je wyświetla. Gdy zmieniasz tekst w panelu, od razu widzisz go na stronie.
Headless rozdziela to na dwie części. Kuchnią zostaje WordPress: panel, edycja wpisów, media, użytkownicy. Salą staje się osobna aplikacja, która pobiera treści i pokazuje je odwiedzającym. Między nimi jest okienko do podawania, czyli API. W samym WordPressie jest wbudowane REST API (od wersji 4.7), a wtyczka WPGraphQL dodaje alternatywę, czyli GraphQL.
Najczęściej do wyświetlania wybiera się Next.js, framework oparty na React, który potrafi przygotować strony z wyprzedzeniem i podawać je bardzo szybko. Ten sam mechanizm działa z innymi frameworkami. W moim projekcie frontendem był Gatsby, komunikacja szła przez GraphQL. Zasady są takie same niezależnie od narzędzia.
Po angielsku mówi się "headless" (bez głowy), bo WordPress zostaje bez warstwy, którą widzi użytkownik. Polskie "WordPress bez głowy" to dosłowne tłumaczenie, wciąż rzadko używane. Jeśli szukasz informacji o WordPressie jako headless CMS, chodzi właśnie o ten układ.
Co headless realnie daje
Są cztery powody, dla których ten układ bywa uzasadniony.
Swobodę interfejsu. Dowolne animacje, nietypowa nawigacja, rozwiązania, których motyw WordPressa nie udźwignie bez walki z jego strukturą.
Te same treści w wielu miejscach. Jeden panel, z którego zasilasz stronę, aplikację mobilną i inne serwisy. To najmocniejszy argument, który nie ma prostego odpowiednika w zwykłym WordPressie.
Rozdzielenie pracy. Zespół frontendu i redaktorzy nie wchodzą sobie w drogę. Redaktor pracuje w znanym panelu, programista w swoim kodzie.
Potencjalnie szybszą stronę. Tu trzeba uważać. W moim projekcie strona ładowała się zauważalnie szybciej i nie będę tego umniejszać. Jednocześnie autorzy poradnika WPBeginner o headless WordPress zaznaczają, że w małych projektach podobny efekt daje zwykła optymalizacja z cache i CDN. Wysoki wynik w PageSpeed da się uzyskać także na zwykłym WordPressie, z lekkim, dedykowanym motywem bez page buildera. Jeśli jedynym powodem jest szybkość, zacznij od tego, co opisałem we wpisie o wolnym sklepie WooCommerce.
Co headless kosztuje (czego nie mówią oferty)
Nie podaję widełek, bo zależą od zakresu. Zamiast tego opisuję, skąd bierze się koszt, żebyś mógł ocenić ofertę.
Dwa systemy zamiast jednego. Osobny hosting dla WordPressa i dla aplikacji, osobne aktualizacje, monitoring, kopie zapasowe. Więcej miejsc, w których coś może przestać działać.
Wtyczki nie działają same z siebie. Wiele wtyczek odpowiada za formularze, SEO, cookies, wyszukiwarkę, pop-upy czy rezerwacje i renderuje swoje elementy przez motyw. W headless motywu nie ma, więc wtyczka zainstalowana w WordPressie niczego nie pokaże na froncie. Jej funkcje trzeba osobno wystawić przez API i osobno zaprogramować po stronie aplikacji albo zastąpić inną usługą. Ten jeden fakt rozstrzygnął o całej historii, którą opisuję niżej.
Brak podglądu przed publikacją. Przyciski "Podgląd" i "Wyświetl" w panelu przestają pokazywać stronę taką, jaka będzie dla odwiedzającego. W moim projekcie podgląd wpisu przed publikacją był praktycznie niemożliwy. Treść pojawiała się na stronie dopiero po publikacji i przebudowaniu aplikacji, a wcześniej redaktor widział ją tylko w edytorze WordPressa. Podgląd da się zbudować (Next.js ma do tego tryb Draft Mode), ale to kolejna funkcja do zaprogramowania. Dla zespołu przyzwyczajonego do edycji "na żywo" to duża zmiana.
Edytor bloków i szablony wymagają tłumaczenia. Każdy nowy typ bloku w Gutenbergu musi mieć odpowiednik w aplikacji. To praca programisty przy każdej nowej potrzebie.
SEO trzeba zaimplementować. Meta tagi, mapa witryny, dane strukturalne, przekierowania i canonicale muszą powstać we froncie. Robiłem migrację SEO z WordPressa na Gatsby z użyciem Yoast SEO: dane z wtyczki wystawiałem przez GraphQL i wykorzystywałem w aplikacji. Da się to zrobić dobrze, ale nie dzieje się samo, a błąd przy migracji kosztuje widoczność w Google. Jeśli planujesz taki krok, przeczytaj najpierw przebudowę sklepu bez utraty SEO.
Ogólnie: niestandardowy frontend to osobny projekt programistyczny, a nie dodatek do istniejącego WordPressa. Jak liczyć koszt w czasie, a nie w dniu startu, pokazuję we wpisach ile kosztuje strona na WordPressie i ile kosztuje sklep WooCommerce.
Tradycyjny WordPress a headless
| Kryterium | Tradycyjny WordPress | Headless |
|---|---|---|
| Liczba systemów do utrzymania | Jeden | Dwa (WordPress i aplikacja) |
| Swoboda wyglądu | Ograniczona motywem | Praktycznie pełna |
| Szybkość | Dobra po optymalizacji (cache, lekki motyw) | Potencjalnie wyższa, ale nie jest gwarancją |
| Wtyczki na froncie | Działają po instalacji | Wymagają osobnej implementacji |
| Podgląd wpisu | Wbudowany | Do zbudowania lub niedostępny |
| Wygoda redaktora | Wysoka | Niższa, zależna od tego, co zbuduje programista |
| SEO | Gotowe po instalacji wtyczki | Do zaimplementowania we froncie |
| Zmiany i nowe funkcje | Często gotowa wtyczka | Zwykle praca programisty |
| Zależność od wykonawcy | Mniejsza | Większa |
| Najlepiej pasuje do | Stron firmowych, blogów, typowych sklepów | Aplikacji, wielu odbiorców treści, niestandardowych interfejsów |
Kiedy headless ma sens
Headless jest uzasadniony, gdy spełniony jest co najmniej jeden z poniższych warunków i masz kogoś, kto to utrzyma.
- Masz aplikację (webową lub mobilną) albo kilka serwisów, które mają korzystać z jednej bazy treści.
- Interfejs jest naprawdę niestandardowy i nie da się go sensownie zrobić w motywie, na przykład ma charakter aplikacji.
- Masz duży ruch, budżet i zespół techniczny, który utrzyma dwa systemy. WPBeginner wskazuje to jako główny warunek.
- Zespół frontendu pracuje już w React albo Next.js i chce zostawić redaktorom znajomy panel WordPressa.
Warto też wiedzieć, że WordPress jako CMS nie ma opłat licencyjnych, w przeciwieństwie do wielu komercyjnych headless CMS-ów rozliczanych abonamentem. Jeśli masz powód, żeby oddzielić treści od wyglądu, to rozsądny kompromis.
Kiedy NIE headless
To najważniejsza część wpisu.
Strona firmowa z kilkoma podstronami i blogiem. Zwykły WordPress z lekkim, dobrze napisanym motywem w zupełności wystarczy. Czy motyw gotowy, czy własny, rozstrzygam we wpisie szablon czy dedykowana strona.
Gdy głównym powodem jest szybkość albo SEO. Najpierw optymalizacja, cache, CDN i porządny motyw. Wysoki wynik w PageSpeed nie wymaga headless.
Typowy sklep WooCommerce. Tu mówię z doświadczenia. Koszyk, finalizacja zamówienia, konta klientów, płatności i integracje z kurierami to obszar, w którym wtyczki są mocno związane z motywem. W headless musisz zbudować tę obsługę na froncie sam.
W sklepie, który wdrażałem, trzeba było dopisać własne połączenia GraphQL dla płatności cyklicznych i integracji z InPost. Moim zdaniem headless nie był tam dobrą decyzją i nie sprowadza się to do technologii. Problemem była komunikacja między osobą odpowiedzialną za produkt a biznesem. Opis funkcjonalności był bardzo słaby i nikt nie powiedział wprost rzeczy, która dziś wydaje się oczywista: zainstalowanie wtyczki w WordPressie nie znaczy, że działa ona na froncie w Gatsby. Wtyczka dodaje funkcję po stronie WordPressa, a frontend musi ją dostać przez API i osobno zaimplementować.
Biznes oczekiwał, że wystarczy wtyczka. Skutek: rozjazd między oczekiwaniami a rzeczywistością i dopisywanie brakujących funkcji ręcznie. Wniosek na przyszłość: przed wyborem headless spisz, które funkcje muszą działać na froncie i kto każdą z nich zaimplementuje. Nie zakładaj, że wtyczka załatwia sprawę.
Brak osoby, która utrzyma dwa systemy. Za rok i za trzy lata ktoś musi aktualizować oba elementy i naprawiać to, co zawiedzie.
Redaktorzy przyzwyczajeni do page buildera i podglądu "tak jak na stronie". W headless dostaną coś innego i muszą to zaakceptować.
Headless zwykle nie jest ulepszeniem istniejącego rozwiązania. To inny zestaw kompromisów.
Sześć pytań, które rozstrzygają
- Czy treści mają trafiać do więcej niż jednego miejsca, na przykład na stronę i do aplikacji?
- Czy interfejs jest naprawdę niestandardowy, czy tylko chcesz, żeby "wyglądał nowocześniej"?
- Czy masz zespół lub wykonawcę, który będzie utrzymywał dwa systemy na stałe?
- Czy redaktorzy zaakceptują inny podgląd i inny sposób pracy?
- Czy każda wtyczka, z której korzystasz, ma swój odpowiednik we froncie i ktoś go zbuduje?
- Czy głównym powodem jest szybkość, którą da się uzyskać taniej?
Jeśli na pierwsze dwa pytania odpowiadasz "nie", prawdopodobnie headless nie jest Ci potrzebny. To decyzja architektoniczna, a nie ulepszenie wyglądu.
Co się zmieniło przez AI
Kilka lat temu dopisanie własnych połączeń między WordPressem a frontendem było żmudną, ręczną pracą. Dziś, przy modelach AI i agentach kodujących, zbudowanie headless, zarówno strony, jak i sklepu, jest o wiele szybsze i pewniejsze. To zmienia rachunek i uczciwie trzeba to przyznać.
Zmiana dotyczy nie tylko samej budowy. AI przyspiesza też utrzymanie rozumiane jako naprawy błędów i wdrażanie zmian, bo to również praca programistyczna.
Nie znika natomiast to, co wynika z samej architektury: są dwa systemy, dwa hostingi, dwa zestawy aktualizacji, odpowiedzialność za awarie w dwóch miejscach, a redaktor nie ma gotowego podglądu. AI obniża koszt pisania kodu, ale nie zmienia faktu, że masz więcej elementów, które mogą zawieść. Przesuwa to granicę opłacalności, ale jej nie likwiduje.
Alternatywy, o których warto wiedzieć
Zwykły WordPress z dobrym motywem i cache zwykle wystarcza. Gdy gotowy motyw ogranicza, pomaga dedykowany motyw bez page buildera. A gdy projekt jest tak naprawdę aplikacją (logowanie użytkowników, panel, funkcje jak w programie), lepszy bywa osobny projekt w Next.js bez WordPressa. Szerzej opisuję to we wpisie czy WordPress ma jeszcze sens.
FAQ
To układ, w którym WordPress przechowuje i zarządza treściami, a osobna aplikacja, na przykład w Next.js, pobiera je przez API i wyświetla odwiedzającym. Panel dla redaktorów zostaje ten sam, zmienia się warstwa, którą widzi użytkownik.
Może być, ale to nie jest gwarancja. W moim projekcie strona ładowała się zauważalnie szybciej. Jednocześnie w małych projektach podobny efekt daje zwykła optymalizacja z cache i CDN, a bardzo dobre wyniki w PageSpeed osiąga się też na dedykowanym motywie WordPressa bez headless.
Może być, ale SEO trzeba zaimplementować we froncie: meta tagi, mapę witryny, dane strukturalne i przekierowania. Przy migracji z istniejącej strony ryzykujesz widoczność, jeśli coś pominiesz. Nie oceniam wpływu na pozycje w ogólności, bo zależy od wykonania.
Zależy od zakresu, dlatego nie podaję widełek. Koszt to praca programisty przy froncie, integracjach i utrzymaniu dwóch systemów, a nie opłata za oprogramowanie. Punkt odniesienia dają koszty zwykłej strony na WordPressie i zwykłego sklepu WooCommerce, które opisuję w osobnych wpisach.
Może, sam to robiłem. Trzeba jednak osobno zbudować koszyk, finalizację zamówienia i obsługę wtyczek, które w zwykłym sklepie działają od razu. Dla typowego polskiego sklepu rzadko się to opłaca.
Po stronie WordPressa tak, ale ich efekty nie pojawią się na froncie same z siebie. Wtyczka musi wystawić swoje dane przez API, a aplikacja musi je wyświetlić. Wtyczki związane z motywem (formularze, cookies, pop-upy, rezerwacje) trzeba zastąpić własnym kodem albo zewnętrzną usługą.
Tak, panel zostaje. Zmienia się natomiast to, co widzisz po zapisaniu: podgląd przed publikacją bywa niedostępny, a zmiana pojawia się na stronie po odświeżeniu lub przebudowaniu aplikacji.
Rozdzielenie warstw może zmniejszyć liczbę elementów dostępnych publicznie, ale nie jest to gwarancja. Dwa systemy to także dwa miejsca do aktualizowania i pilnowania. Bezpieczeństwo zależy od wykonania i utrzymania, nie od samej architektury.
Podsumowanie
Headless WordPress to narzędzie do konkretnych problemów: wielu odbiorców tych samych treści, niestandardowego interfejsu, zespołu technicznego, który to utrzyma. Nie jest "wersją premium" zwykłego WordPressa. AI sprawiło, że jest tańszy w budowie, ale nie zmieniło tego, że masz dwa systemy zamiast jednego.
Jeśli nie jesteś pewien, zacznij od zwykłego WordPressa i go zoptymalizuj. A jeśli chcesz sprawdzić, czy Twój przypadek naprawdę wymaga headless, umów bezpłatną konsultację - powiem wprost, a bardzo często odpowiedź będzie brzmiała "nie". Jak wygląda współpraca krok po kroku, opisuję na stronie procesu.