Co to jest Headless CMS i kiedy warto z niego korzystać?

Współcześnie biznes przy publikowaniu contentu korzysta z coraz większej ilości kanałów. Są to nie tylko strony internetowe, ale np. social media, aplikacje webowe, kioski podłączone do sieci czy nawet urządzenia IoT. Klasyczne systemy zarządzania treścią nie są stworzone do dystrybucji wielokanałowej, dlatego coraz częściej wykorzystywany jest Headless CMS. Czym jest i dlaczego warto się nim zainteresować?

Jak działa „klasyczny” CMS

Korzystając z CMS-a takiego jak np. WordPress czy Joomla, mamy do dyspozycji interfejs graficzny, za pomocą którego tworzymy i edytujemy treści. Używamy do tego edytorów WYSIWYG (pozwalających na zobaczenie wprowadzanych zmian) lub edytorów HTML. 

Tradycyjny CMS (taki jak WordPress) składa się z bazy danych, w której przechowywana jest treść i panelu administracyjnego pozwalającego nią zarządzać. Ponadto zawiera API i warstwę front-endową, wyświetlającą content.

2 i 3 akapit w tej sekcji: To dostarczanie do jednego kanału zamieniłbym właśnie na SSR i opisał proces, że użytkownik wysyła zapytanie, serwer musi to przemielić, ogarnąć całą logike i dopiero wtedy wyświetla strone. Potem gdzieś porównałbym to z SSG, czyli static site generation (tak jak mniej więcej działa to w Jamstack), czyli do wyświetlenia strony nie potrzebujemy odpowiedzi z serwera od razu. Wszystkie assety na przykład są statyczną częścią strony.

System taki ma jednak swoje ograniczenia. Został stworzony z myślą, aby dostarczać content tylko do jednego kanału – strony internetowej. Dlatego też kod zawierający treść jest połączony z kodem definiującym jej wyświetlanie. 

Sprawia to, że aby ten sam content wyświetlać w różnych kanałach, czy na różnych urządzeniach potrzebne są dodatkowe wtyczki (jeśli to w ogóle możliwe). W innym przypadku jesteśmy zmuszeni do wprowadzania tej samej treści w systemie każdego kanału osobno.

Stało się to w ostatnich latach tym bardziej kłopotliwe, że istnieje wiele urządzeń i środowisk, które wymagają dostarczania do nich contentu. Są to nie tylko smartfony i tablety, ale także telewizory czy np. cyfrowe kioski. 

Znaczenie ma także wzrost ilości urządzeń IoT (internetu rzeczy). Oprócz inteligentnych głośników czy czujników pojawiają się także zestawy VR, a nawet samochody podłączone do sieci. W takim przypadku CMS sprzężony z warstwą front-endową jest uciążliwy w obsłudze.

Jak działa Headless CMS?

W Headless CMS określenie „headless” (bez głowy) oznacza oddzielenie warstwy zarządzania treścią od warstwy jej wyświetlania – front-endu (czyli głowy). Dzięki temu możliwe jest jednorazowe wprowadzanie treści i publikowanie jej w dowolnych kanałach, na dowolnych urządzeniach.

Do przesyłania contentu wykorzystywany jest interfejs API, poprzez który treści trafiają do urządzeń bez szablonów w przeciwieństwie do tradycyjnych systemów CMS. Dzięki temu programiści mogą tworzyć indywidualne szablony dla każdego z kanałów. Treść wpisywana jest tylko raz i wyświetlana zarówno na stronie internetowej, w sklepie internetowym, smartfonie, smartwatchu czy innym urządzeniu.

Kiedy warto korzystać z Headless CMS?

  • gdy potrzebujesz elastycznie dostosować front-end

Przygotowując warstwę wizualną CMS-a programiści mają pełną dowolność w wyborze rozwiązań. Mogą wybierać język programowania wg własnych preferencji czy też stosować różne frameworki. Pozwala to na tworzenie m.in. nowocześniejszych i bardziej atrakcyjnych witryn internetowych.

  • gdy chcesz wykorzystywać treści na różnych urządzeniach

Headless CMS opiera się na przechowywaniu danych, pozwalając administratorowi prezentować wprowadzoną przez siebie treść na dowolnym typie urządzenia i przy użyciu różnych kanałów. Aktualizacja contentu staje się dzięki temu szybka i wygodna.

Jest to możliwe dzięki interfejsom API, które umożliwiają komunikację między różnymi technologiami (programami i kanałami). Interfejsy mogą także przesyłać dane z powrotem do CMS-a (np. dotyczące aktywności i preferencji użytkownika końcowego). 

  • jeżeli potrzebujesz odciąć pracę nad zarządzaniem treścią od prac dotyczących wyglądu kanału

Dzięki Headless CMS administratorzy treści mogą wprowadzać je nawet w trakcie przygotowywania front-endu lub dokonywania w nim zmian przez programistów. W przypadku klasycznych systemów CMS warstwa wizualna systemu musi być gotowa, zanim marketerzy zaczną działania. Gdy wprowadzane są zmiany, niezbędna jest przerwa w ich pracy.

  • gdy zależy Ci na większym bezpieczeństwie informacji

W klasycznym CMS-ie rodzaju WordPressa duży wpływ na bezpieczeństwo danych mają twórcy systemu oraz wtyczek. Od tego, czy dostrzegą ewentualne luki w zabezpieczeniach i uwzględnią poprawki w aktualizacjach, zależy odporność CMS-a i pluginów na ataki hakerów.

CMS-y modelu open-source cechują się także otwartym kodem, dzięki czemu hakerom łatwiej jest go analizować i szukać luk w zabezpieczeniach. W przypadku np. podejścia JAMStack, które można zastosować w systemach Headless, dostęp do kodu źródłowego jest niemożliwy, ponieważ pisany jest on od zera. 

Headless CMS pozwala nam mieć zatem większy wpływ na bezpieczeństwo systemu i możemy sami o nie na bieżąco dbać, używając wybranych rozwiązań. Dzięki temu nasze dane będą lepiej chronione.

  • jeśli chcesz korzystać z CMS-a mogącego się przystosować do nowych technologii

Każdego roku na rynku pojawiają się nowe urządzenia, którym można dostarczać treści. Headless CMS jest rozwiązaniem przyszłościowym, gdyż może współpracować z każdym kanałem. Dzięki temu unikniemy sytuacji, gdy system trzeba będzie specjalnie dostosowywać pod kątem nowych urządzeń lub wprowadzać dane niezależnie. 

  • jeżeli zależy ci na skalowalności aplikacji

Dzięki użyciu Headless CMS wraz z nowoczesnymi frameworkami typu React czy Vue.js możemy łatwiej rozwijać aplikację o kolejne funkcjonalności. W przypadku, gdy chcemy rozbudować projekt, programista nie musi wgłębiać się w strukturę całości kodu, ale z łatwością odnajdzie potrzebny mu komponent. Umożliwia to szybsze wdrożenie nowych funkcjonalności. 

  • gdy chcesz wykorzystać SPA (Single Page Application)

Headless pozwala łatwiej tworzyć aplikacje jednostronicowe, czyli SPA. Działają one w przeglądarce i nie wymagają przeładowywania strony, gdy się z nich korzysta. Niezbędne zasoby pobierane są podczas pierwszej wizyty użytkownika lub w miarę potrzeby dynamicznie doładowywane w tle. 

Dzięki temu SPA działają szybciej, cechują się lepszym UX czy mniej obciążają jego urządzenie. Jednorazowe ładowanie się strony nie musi mieć także negatywnego wpływu na SEO, gdyż wyszukiwarki w pełni indeksują aplikacje jednostronicowe. Możliwe jest także stosowanie renderowania po stronie serwera (SSR), renderowania wstępnego czy odpowiednio utworzonych tagów meta i map witryn.

Wady Headless CMS

  • ograniczone możliwości marketerów

Headless CMS pozbawiony jest wielu wygodnych i przyjaznych dla użytkownika funkcji, jak blogowanie czy edycja WYSIWYG (chociaż wyjątkiem jest np. WordPress służący jako Headless). Funkcjonalności zredukowane są do tych najbardziej potrzebnych. 

Marketerzy nie mogą także samodzielnie projektować wyglądu stron oraz nie otrzymują podglądu ich treści. Może to być przeszkodą jeśli potrzebują tworzyć więcej spersonalizowanych stron. Dlatego też korzystanie z Headless CMS jest korzystne w przypadku, gdy układ contentu jest stały.

  • wyższy koszt od tradycyjnego CMS-a

Wdrażając Headless CMS sami musimy konstruować rozwiązania frontendowe lub korzystać z rozwiązań innych firm. Oznacza to dodatkowe wydatki oraz poświęcenie nieraz dużej ilości czasu programistów. Będziemy również zmuszeni do samodzielnego poprawiania ewentualnych błędów w warstwie wizualnej systemu.

Co to jest CMS hybrydowy

Developerzy, dostrzegając zalety „bezgłowych” systemów zarządzania treścią, jak i widząc ich wady postanowili stworzyć rozwiązanie będące połączeniem CMS-a Headless i klasycznego. Hybrydowy CMS (inaczej odsprzężony lub opcjonalny) pozwala na dostarczanie contentu do różnych kanałów tak jak Headless. Jednocześnie umożliwia administratorom treści korzystanie z interfejsu, który przypomina ten klasycznych CMS-ów. 

W CMS-ie hybrydowym front-end i back-end nie są ze sobą ściśle powiązane i komunikują się poprzez API. Mimo to marketer ma do dyspozycji narzędzia umożliwiające podgląd publikowanej treści (WYSIWYG) i jej bezpośrednią edycję (także za pomocą metody „przeciągnij i upuść”). Może także personalizować i targetować content, również pod kątem odpowiedniego kanału.

Hybrydowy CMS w pewnym stopniu uniezależnia osoby administrujące treścią od działu IT. Najważniejsze funkcjonalności już istnieją w systemie i nie ma potrzeby, by programiści tworzyli je od podstaw, jak w „surowym” Headless CMS. Zmniejszają się przez to koszty oraz skraca czas potrzebny na rozpoczęcie działań. Dział IT zostaje także odciążony, nie musząc wspomagać na bieżąco twórców treści.

Przyjazne interfejsy systemów hybrydowych sprawiają również, że marketerzy z większą łatwości publikują content. Jednocześnie CMS-y te są otwarte na współpracę z różnego rodzaju urządzeniami, a także zewnętrznym oprogramowaniem. Dotyczy to np. systemów marketingowych, księgowych czy CRM, z którymi integracja możliwa jest dzięki API.

Hybryda czy Headless?

Mimo swoich zalet CMS hybrydowy ma pewne ograniczenia. Wciąż, podobnie jak klasyczne systemy zarządzania treścią zawiera front-end, co może utrudniać dostarczanie wielokanałowe. Mamy także do czynienia z mniejszą elastycznością podczas dynamicznego publikowania contentu na różnych urządzeniach. Ponadto kształtowanie CMS-a wg własnych potrzeb będzie trudniejsze (możliwe właściwie tylko w systemach open-source).

Headless CMS sprawdzi się zatem lepiej w przypadku wielokanałowej obsługi dużej ilości urządzeń. Dostosujemy go do własnych wymagań i zapewnimy optymalną dystrybucję treści. Jeśli jednak wykorzystujemy omnichannel na mniejszą skalę, CMS hybrydowy pozwoli nam szybciej zacząć działania oraz ułatwi pracę marketerom.

Tak czy inaczej, oba rodzaje systemów mają wyraźną przewagę nad tradycyjnymi CMS-ami, w których warstwa front-endowa jest połączona z back-endem. Dzięki „bezgłowym” systemom programiści zyskują możliwość używania API, aby dostarczać treści do różnych kanałów. 

Jednocześnie marketerzy nie są zmuszeni do wprowadzania tego samego contentu w interfejsach różnych urządzeń. Stanowi to otwarcie się na przyszłość, którą jest obsługa wielu kanałów.

Cookies

Nasza strona internetowa używa plików cookies (tzw. ciasteczka) w celach statystycznych, reklamowych oraz funkcjonalnych. Każdy może zaakceptować pliki cookies albo ma możliwość wyłączenia ich w przeglądarce, dzięki czemu nie będą zbierane żadne informacje. Czytaj więcej


Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/gogomedia/public/blog/wp-includes/functions.php on line 4757

Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/gogomedia/public/blog/wp-includes/functions.php on line 4757