Słowo „headless” w przekładzie
„Headless” to niefortunny kawałek żargonu na całkiem prostą ideę. W tradycyjnym systemie zarządzania treścią część, która przechowuje treści i nimi zarządza, oraz część, która wyświetla je odwiedzającym, są połączone w jednym produkcie. Headless CMS je rozdziela. Zachowuje zarządzanie treścią i usuwa wbudowany front-end, czyli „głowę”, dostarczając treści przez API.
W praktyce oznacza to, że headless CMS to miejsce do tworzenia i porządkowania treści oraz sposób, w jaki inne systemy mogą o te treści poprosić i wyświetlić je, jak tylko chcą. CMS nie decyduje już, jak wygląda strona. Staje się źródłem treści, a warstwę prezentacji osobno budują developerzy.
Dlaczego istnieje ten podział
Podział istnieje, bo treści coraz częściej muszą pojawiać się w więcej niż jednym miejscu. Tradycyjny CMS zakłada, że treść ma jedno miejsce docelowe: stronę, z którą jest połączona. Ale wiele firm publikuje dziś te same treści na stronie, w aplikacji mobilnej, na ekranach cyfrowych, na platformie partnera albo we wszystkich tych miejscach naraz.
W tradycyjnym CMS obsługa wielu kanałów oznacza albo prowadzenie kilku systemów, albo walkę z narzędziem zaprojektowanym pod jedno wyjście. Headless CMS traktuje treści jak uporządkowane dane, o które może poprosić każdy kanał. Piszesz raz, a strona, aplikacja i wszystko inne wyświetlają je na swój sposób. To właśnie rozdzielenie to umożliwia.
Co zyskujesz
Pierwszy zysk to publikacja wielokanałowa: jedno źródło treści zasila wiele miejsc, bez powielania. Drugi to swoboda front-endu. Developerzy nie są już ograniczeni systemem szablonów czy motywów CMS-a. Mogą budować stronę w nowoczesnych frameworkach i narzędziach, co zwykle oznacza lepszą wydajność i lepiej zaprojektowaną stronę.
Trzeci zysk to trwałość. Ponieważ treści są uporządkowane i siedzą za API, nie są splątane z jednym konkretnym projektem strony. Redesign staje się projektem front-endowym, który nie rusza treści, zamiast migracją. A ponieważ treści nie są zamknięte w warstwie prezentacji, przeniesienie ich później gdzie indziej jest dużo mniej bolesne.
Co bierzesz na siebie
Kompromis polega na tym, że headless CMS nie daje Ci strony. Daje Ci zarządzane treści i API. Cały front-end, czyli to, co widzą odwiedzający, musi zostać zaprojektowany i zbudowany przez developerów. W tradycyjnym CMS używalna strona może powstać szybko i przy niewielkim nakładzie inżynierskim. W headless CMS strona to prawdziwy projekt developerski.
To oznacza, że podejście headless wymaga kompetencji developerskich, we własnym zespole lub u partnera, i zwykle więcej kosztuje na starcie. Jest też więcej do poskładania: hosting front-endu, proces wdrożeniowy i połączenie między CMS-em a stroną. Nic z tego nie jest egzotyczne, ale to praca, którą tradycyjny CMS w pakiecie wziąłby na siebie.
Kto powinien z niego korzystać, a kto nie
Headless CMS świetnie pasuje do firmy, która publikuje w więcej niż jednym kanale, traktuje wydajność strony i jakość inżynierską jako priorytety albo spodziewa się z czasem redesignu lub zmiany platformy i chce, by treści przetrwały to nienaruszone. Dla takich firm dodatkowy koszt konfiguracji kupuje realne, trwałe korzyści.
Słabo pasuje do firmy, która potrzebuje jednej, dość standardowej strony marketingowej, ma ograniczony budżet i nie ma wsparcia developerskiego. Dla takiej firmy tradycyjny CMS szybciej i taniej daje działającą stronę, a elastyczność headless w większości pozostałaby niewykorzystana. Płacenie za możliwości, z których nie skorzystasz, to nie wyrafinowanie, tylko marnotrawstwo.
Jak podjąć decyzję
Decyzja zależy od dwóch pytań. Po pierwsze, czy Twoje treści muszą pojawiać się w więcej niż jednym miejscu, teraz lub w realistycznym czasie życia projektu? Jeśli tak, model headless wykonuje dla Ciebie prawdziwą pracę. Jeśli jedynym miejscem docelowym jest jedna strona, większość jego przewagi jest teoretyczna.
Po drugie, czy firma sfinansuje development front-endu? Headless CMS zakłada zbudowany front-end i inżynierów, którzy go utrzymają. Mając te kompetencje, headless zwykle daje szybszy, trwalszy i bardziej elastyczny efekt. Bez nich uczciwym wyborem jest tradycyjny CMS. Dopasuj model do kanałów, w których publikujesz, i do pracy inżynierskiej, którą jesteś w stanie utrzymać, a odpowiedź zwykle będzie jasna.
