Czym jest headless commerce
W tradycyjnym sklepie internetowym frontend (to, co widzi klient) i backend (baza produktów, zamówienia, płatności) działają jako jeden system. Szablon sklepu jest częścią platformy — renderuje się na tym samym serwerze, korzysta z tych samych zasobów i podlega tym samym ograniczeniom.
W architekturze headless frontend jest odseparowany od backendu. Platforma e-commerce (Shoper, PrestaShop, WooCommerce, Shopify) nadal zarządza produktami, zamówieniami i płatnościami — ale warstwa wizualna sklepu działa osobno, na własnej infrastrukturze, i komunikuje się z backendem wyłącznie przez API.
Jak to działa technicznie
W praktyce headless storefront opiera się na podziale domen. Główna domena sklepu (np. twojsklep.pl) wskazuje na serwer frontendu, a checkout działa na osobnej subdomenie (np. checkout.twojsklep.pl) obsługiwanej przez platformę e-commerce.
Klient wchodzi na twojsklep.pl
DNS kieruje ruch na serwer frontendu. Strona główna, kategorie, produkty i wszystkie elementy sklepu renderują się na infrastrukturze frontendowej.
Przegląda sklep
Wyszukiwarka, filtrowanie, rekomendacje, chat — wszystko działa na frontendzie. Backend odpytywany jest tylko po dane (produkty, ceny, stany).
Klika „Przejdź do kasy”
Przekierowanie na checkout.twojsklep.pl — subdomenę obsługiwaną przez platformę e-commerce.
Finalizuje zamówienie
Koszyk, płatności, wybór dostawy, potwierdzenie — standardowy checkout platformy, bez żadnych zmian.
Z perspektywy klienta zmiana jest niewidoczna — przegląda sklep pod tą samą domeną, a przejście do koszyka odbywa się płynnie. Z perspektywy technicznej frontend i backend to dwa niezależne systemy połączone przez API.
Podział domen
- Strona główna, kategorie, produkty, wyszukiwarka
- Serwowany z infrastruktury frontendowej
- Pełna kontrola nad wydajnością i UX
- Koszyk, płatności, finalizacja zamówienia
- Serwowany z platformy e-commerce
- Bez zmian — standardowy checkout platformy
Tradycyjny szablon vs headless
- Frontend renderowany przez platformę — wydajność zależy od serwera, szablonu i zainstalowanych modułów
- Każdy moduł/wtyczka dodaje własne skrypty i style — łączny czas ładowania rośnie z każdym dodatkiem
- Zmiany w wyglądzie ograniczone do tego, co oferuje szablon i platforma
- Podatności modułów mają bezpośredni dostęp do backendu
- Frontend na osobnej infrastrukturze — wydajność niezależna od backendu
- Kontrola nad każdym skryptem i zasobem, który ładuje się na stronie
- Pełna swoboda w projektowaniu interfejsu — brak ograniczeń szablonu
- Frontend odizolowany od backendu — mniejsza powierzchnia ataku
Izolacja frontendu od backendu
W tradycyjnym modelu szablon ma bezpośredni dostęp do bazy danych i wewnętrznych funkcji platformy. Podatność w motywie lub module może otworzyć drogę do danych klientów, zamówień czy panelu admina.
W architekturze headless frontend komunikuje się z backendem wyłącznie przez API — nie ma dostępu do bazy, systemu plików ani panelu administracyjnego. To dwie odseparowane warstwy:
- Mniejsza powierzchnia ataku — podatność na frontendzie nie daje dostępu do backendu i odwrotnie
- Brak nieaktualizowanych modułów — w tradycyjnym modelu każdy zainstalowany moduł (szczególnie na WooCommerce i PrestaShop) to potencjalny wektor ataku. Headless eliminuje tę warstwę
- Niezależna skalowalność — wzrost ruchu na frontendzie nie obciąża serwera backendowego
Co się zmienia w codziennej pracy
Z perspektywy właściciela sklepu headless zmienia tylko jedną rzecz — warstwę frontendową. Zarządzanie produktami, zamówieniami, klientami, cenami i promocjami odbywa się nadal z panelu platformy, dokładnie tak jak dotychczas.
- Produkty, kategorie, warianty
- Ceny, promocje, stany magazynowe
- Zamówienia, klienci, faktury
- Checkout, płatności, kurier
- Wygląd sklepu — zarządzany przez dostawcę frontendu
- Wydajność — niezależna od platformy
- Integracje frontendowe (search, chat, rekomendacje itp.) — natywnie w kodzie frontendu
Kiedy headless ma sens
Headless nie jest rozwiązaniem dla każdego sklepu. Ma sens, gdy:
- Wydajność jest priorytetem — szablon platformy nie zapewnia wystarczająco szybkiego ładowania, a optymalizacja uderza w ograniczenia systemu
- Potrzebujesz pełnej kontroli nad UX — układ strony, nawigacja, wyszukiwarka, rekomendacje — chcesz, żeby frontend działał dokładnie tak, jak tego potrzebujesz
- Masz wiele integracji frontendowych — każdy dodatkowy moduł (chat, search, rekomendacje, consent banner) spowalnia tradycyjny szablon. W headless są częścią jednego, zoptymalizowanego frontendu
- Zależy ci na bezpieczeństwie — izolacja frontendu od backendu zmniejsza ryzyko związane z podatnościami modułów
Headless raczej nie ma sensu, gdy sklep jest mały, szablon platformy wystarczająco szybki, a zakres integracji ograniczony. Wdrożenie headless to zmiana architektury — przynosi korzyści przy skali, ale wymaga utrzymania osobnej warstwy frontendowej.
Headless storefront od Witly
Witly oferuje gotowy headless storefront dla najpopularniejszych platform e-commerce. Każdy storefront zawiera wbudowaną wyszukiwarkę AI, rekomendacje, chat i narzędzia konwersji — natywnie zintegrowane z frontendem.