Frontend Vue.js dla systemu B2B – kiedy ma sens i jak go zaprojektować?

Vue.js ma sens w części systemu B2B, z której korzystają klienci – w portalu zamówień, sklepie B2B czy katalogu z cenami indywidualnymi – wtedy, gdy interfejs jest mocno interaktywny: koszyk z wieloma pozycjami, filtry, konfiguratory, szybkie zamawianie po indeksie. Nie każda strona portalu potrzebuje jednak aplikacji po stronie przeglądarki. Część publiczną (katalog, karty produktów, strony kategorii) zwykle lepiej renderować po stronie serwera, a Vue dokładać tam, gdzie klient faktycznie coś klika. Poniżej opisujemy, jak podjąć tę decyzję i na co uważać przy frontendzie dla odbiorców zewnętrznych, a nie dla własnego zespołu.

Frontend dla klienta to inny projekt niż panel admina

Panel administracyjny ma kilkunastu lub kilkudziesięciu użytkowników, których da się przeszkolić, którzy pracują na firmowych laptopach i znają proces. Portal klienta B2B działa w odwrotnych warunkach:

• użytkownicy są anonimowi albo słabo znani – kupiec u dystrybutora, magazynier, który raz w tygodniu zamawia materiały, księgowa szukająca faktury,
• urządzenia i łącza są przypadkowe – starszy komputer w biurze, telefon na budowie, tablet w hali, sieć komórkowa w terenie,
• nikt nie przejdzie szkolenia – interfejs musi być zrozumiały od pierwszego wejścia,
• część treści ma być widoczna w Google – katalog i karty produktów to często główne źródło ruchu.

Dlatego wzorce z panelu (gęste tabele, dziesiątki kolumn, skróty klawiszowe) opisujemy osobno w artykule o Vue.js we frontendzie panelu administracyjnego B2B. Tutaj skupiamy się na tym, co widzi klient.

Trzy modele renderowania i kiedy który wybrać

Renderowanie serwerowe z „wyspami” Vue

Strony generuje backend (np. Laravel z Blade), a Vue montuje się tylko w wybranych miejscach: koszyk, wyszukiwarka z podpowiedziami, konfigurator, formularz szybkiego zamówienia. To dobry wybór, gdy:

• większość ruchu to przeglądanie katalogu,
• zależy Ci na indeksacji i szybkim pierwszym wyświetleniu,
• zespół jest mocniejszy po stronie backendu.

Minusem jest podział logiki interfejsu między szablony serwerowe i komponenty, który trzeba pilnować konwencjami.

Aplikacja Vue z Inertia lub Nuxt

Cały portal zachowuje się jak aplikacja (przejścia bez przeładowania, stan koszyka w pamięci), ale pierwsze renderowanie może odbywać się na serwerze – przez tryb SSR w Inertia albo przez Nuxt. Sprawdza się, gdy portal jest głównie narzędziem pracy zalogowanych klientów, a część publiczna jest mniejsza. Porównanie Inertia z osobnym API opisujemy w tekście Vue, Laravel i Inertia w panelu B2B.

Czysta SPA na osobnym API

Frontend (Vue albo React) jest osobną aplikacją, która rozmawia z backendem wyłącznie przez API. Uzasadnione, gdy ten sam backend obsługuje też aplikację mobilną, integracje partnerów albo kilka różnych frontów. Dla części publicznej bez SSR to zwykle zły pomysł: roboty wyszukiwarek muszą wykonać JavaScript, żeby zobaczyć treść, a użytkownik czeka na pobranie całej aplikacji przed zobaczeniem pierwszego produktu.

Vue czy React?

W portalach klienta różnica między Vue 3 a Reactem rzadko decyduje o sukcesie. Ważniejsze są: kompetencje zespołu, który będzie projekt utrzymywał latami, spójność z resztą systemu i dostępność bibliotek do tabel, formularzy i dat. Jeśli masz jeszcze frontend na Vue 2, pamiętaj, że jego wsparcie zakończyło się 31 grudnia 2023 roku – nowe moduły warto pisać już w Vue 3 i planować migrację starych.

SEO części publicznej

Jeżeli katalog ma zdobywać ruch z wyszukiwarki, kilka rzeczy musi działać niezależnie od wybranego frameworka:

1. Treść w HTML od razu – nazwa, opis, parametry i ceny katalogowe (jeśli są publiczne) mają być w odpowiedzi serwera, a nie doładowywane po kliknięciu.
2. Prawdziwe adresy URL – każda kategoria, produkt i sensowna kombinacja filtrów ma własny adres; żadnych widoków dostępnych tylko przez stan aplikacji.
3. Zwykłe linki `<a href>` – nawigacja przez przyciski z obsługą kliknięcia w JavaScript jest niewidoczna dla robotów.
4. Meta dane i canonical generowane per strona, także przy nawigacji po stronie klienta.
5. Rozdzielenie treści publicznych i tych po zalogowaniu – ceny indywidualne, stany dla danego klienta i historia zamówień nie powinny trafiać do HTML-a części publicznej.

Samą strukturę katalogu, filtrów i canonicali omawiamy w osobnym wpisie o katalogu produktowym i SEO.

Wydajność na słabych łączach

Klient B2B nie zawsze siedzi w biurze na światłowodzie. Kilka zasad, które sprawdzają się w praktyce:

• dziel kod na trasy – kod konfiguratora nie powinien się ładować na stronie logowania,
• ogranicz ciężkie biblioteki – komponent tabeli z setką funkcji, z których używasz trzech, kosztuje każdego użytkownika,
• stronicuj i doładowuj dane po stronie serwera – nie wysyłaj do przeglądarki całego katalogu ani całej historii zamówień,
• pokazuj szkielet i stan ładowania, zamiast pustego ekranu,
• optymalizuj obrazy (rozmiary responsywne, nowoczesne formaty, leniwe ładowanie poniżej pierwszego ekranu),
• testuj na wolnym profilu sieci i słabszym telefonie, nie tylko na komputerze programisty.

Od 2024 roku jednym z Core Web Vitals jest INP (Interaction to Next Paint), czyli czas reakcji na interakcję. W portalach opartych na Vue to właśnie INP najczęściej wypada słabo: kliknięcie filtra uruchamia przeliczenie dużej listy w głównym wątku i interfejs „zamarza”. Rozwiązaniem jest przeniesienie filtrowania na serwer, debounce przy wpisywaniu i unikanie renderowania setek wierszy naraz.

Dostępność

Dostępność w portalu klienta to nie tylko kwestia zgodności, ale też zwykłej używalności: dobra obsługa z klawiatury przyspiesza pracę kupca, który składa kilkadziesiąt pozycji. Minimum, które warto wpisać do kryteriów akceptacji:

• każda akcja dostępna z klawiatury, z widocznym fokusem,
• etykiety pól formularzy powiązane z polami, komunikaty błędów przy polu i odczytywane przez czytniki ekranu,
• kontrast tekstu i statusów zgodny z WCAG, a statusy nie oznaczane wyłącznie kolorem,
• modale, które zatrzymują fokus i dają się zamknąć klawiszem Esc,
• dynamiczne zmiany (np. dodanie do koszyka) ogłaszane przez regiony `aria-live`.

Europejski akt o dostępności stosuje się od 28 czerwca 2025 roku przede wszystkim do usług kierowanych do konsumentów. Czy obejmuje Twój portal, zależy od modelu sprzedaży – warto to sprawdzić, ale dobre praktyki opłacają się niezależnie od wymogów.

Typowe błędy we frontendzie portalu klienta

• przeniesienie gęstości panelu admina do klienta – dwadzieścia kolumn w tabeli zamówień, których klient nie rozumie,
• brak adresów URL dla stanów – klient nie może wysłać handlowcowi linku do przefiltrowanej listy,
• ceny liczone we frontendzie – jedyną prawdą jest backend; frontend tylko pokazuje wynik,
• brak obsługi błędów sieci – koszyk znika po chwilowej utracie połączenia,
• SPA dla części publicznej bez SSR – katalog nie pojawia się w wynikach wyszukiwania.

Od czego zacząć

Zanim wybierzesz framework, spisz trzy rzeczy: które strony mają być widoczne w wyszukiwarce, jakie są trzy najczęstsze zadania klienta w portalu oraz na jakich urządzeniach i łączach pracują Twoi odbiorcy. Na tej podstawie da się zdecydować, gdzie wystarczy renderowanie serwerowe, a gdzie potrzebna jest pełna aplikacja Vue. Jeśli chcesz, żebyśmy przeszli przez to razem, zobacz, jak podchodzimy do tworzenia frontendu Vue.js, i napisz do nas – zaczniemy od przeglądu Twojego obecnego portalu lub makiet.