Staffbase

Głównym problemem był brak spójności i ciągła niestabilność. Każda instancja WordPressa miała własny motyw, zbiór wtyczek i nakładające się na siebie modyfikacje. W efekcie wtyczki często się gryzły po aktualizacjach, a cała strona działała o wiele za wolno. Ten sam element potrafił wyglądać inaczej w zależności od tego, w której części serwisu się znalazł. Redaktorzy albo walczyli z page builderem, albo prosili dewelopera o każdą nową podstronę.

Nie chodziło więc o sam odświeżony wygląd. Rozłożyliśmy istniejące strony na powtarzalne bloki i każdy zdefiniowaliśmy tylko raz: jakie ma pola, które z nich są obowiązkowe i jak wygląda na ekranie telefonu. Dzisiaj tych bloków jest prawie sześćdziesiąt. Redaktorzy wchodzą do Storybloka i składają je tak, jak potrzebują, mając pewność, że kod pod spodem pozostaje czysty, stabilny i szybki.

Bo jedną aplikację utrzymuje się dużo prościej niż dwie. Osobny frontend to druga infrastruktura, drugi proces wdrożeniowy i drugi projekt do pilnowania. Strona firmowa ma być przede wszystkim szybka, dobrze widoczna w Google i łatwa w edycji, a do tego taka konstrukcja nie była potrzebna.

Storyblok dostarcza treści, a Symfony renderuje z nich pełny HTML na serwerze. Przeglądarka i roboty Google od razu dostają kompletną stronę. Przy okazji rozbudowaliśmy Storyblok Symfony bundle oraz klienta PHP API i udostępniliśmy zmiany społeczności open source.

Za interaktywność odpowiada Symfony UX. Każdy blok to Twig Component z własną klasą i szablonem, więc zmienia się go w jednym miejscu. Wyszukiwarkę, filtry wydarzeń i doładowywanie wpisów zrobiliśmy na Live Components: komponent przelicza się na serwerze, a w przeglądarce podmienia się tylko zmieniony fragment. Drobne interakcje, jak karuzele czy zakładki, obsługują lekkie kontrolery Stimulus. Użytkownik dostaje płynnie działającą stronę, a my nie musimy budować drugiego frontendu.

Bo dzięki temu każdy element interfejsu robi dokładnie to, czego wymaga serwis — i nic ponadto. Gotowe biblioteki czy paczki z npm przynoszą ze sobą masę niepotrzebnych funkcji i stylowania, których nikt nie używa, a przeglądarka i tak musi je pobrać, przetworzyć i wykonać. Nasze komponenty są lekkie i szybkie.

Drugi powód to pełna kontrola nad dostępnością (a11y). Każdy element od pierwszej linijki budowaliśmy z myślą o obsłudze z klawiatury i wsparciu dla czytników ekranu. Nie musieliśmy nadpisywać ani „naprawiać” cudzego kodu, żeby spełnić standardy. A ponieważ redakcja składa strony wyłącznie z tak przygotowanych klocków, każda nowa podstrona jest dostępna i wydajna.

Kolory, odstępy, typografia i breakpointy zostały zdefiniowane w konfiguracji Tailwinda raz, a wszystkie komponenty korzystają wyłącznie z tych wartości. Jeśli ktoś w kodzie użyje niestandardowego marginesu, widać to od razu podczas code review.

Do tego dochodzi skala: ponad trzydzieści bloków występuje w pięciu wersjach kolorystycznych i w kilku wariantach układu. Dlatego stworzyliśmy style guide — wewnętrzną stronę, na której widać każdy komponent we wszystkich możliwych konfiguracjach. Każdy nowy blok najpierw sprawdzamy tam, a dopiero potem trafia do edytora dla redakcji.

Warstwowo, bo każdy błąd ma swoje miejsce, w którym najtaniej go złapać.

Pierwszą warstwą jest sam blok. Każdy komponent ma w kodzie umowę ze Storyblokiem: które pola są wymagane, ile elementów może zawierać i jakie motywy są dozwolone. Jeśli treść nie spełnia tej umowy, błąd pojawia się w podglądzie, zanim ktokolwiek kliknie „Publish”. Pilnują tego automatyczne testy jednostkowe i integracyjne szablonów, a przy każdym pull requeście uruchamiamy komplet kontroli w pipeline CI/CD: analizę statyczną, lintery dla Twiga i JavaScriptu, a nawet sprawdzanie pisowni.

Drugą warstwą są ludzie. Każdy komponent najpierw powstaje w style guidzie, gdzie sprawdzamy go we wszystkich motywach i wariantach, na najdłuższych prawdziwych treściach i na prawdziwych telefonach — uwzględniając specyfikę fontu japońskiego czy długie niemieckie nagłówki. Potem trafia na własne środowisko podglądu, czyli pełną kopię strony. Tam design ocenia wygląd, a redakcja Staffbase buduje z niego prawdziwą stronę. Gdy redaktor składa landing page z nowego bloku i nic go nie zaskakuje, wiem, że komponent jest gotowy.

Nowe treści powstają o najróżniejszych porach, często wtedy, gdy nikt z deweloperów nie jest online. Jako agencja Storyblok wiedzieliśmy, że kluczowe jest stworzenie bezpiecznego procesu edycji bez ryzyka, że niegotowa treść trafi na żywą stronę.

W Storybloku wersje robocze (Draft) są oddzielone od opublikowanych (Published), co współgra z wbudowanym systemem akceptacji (Workflow). Redaktor układa nową podstronę z gotowych bloków w wizualnym edytorze, mając natychmiastowy podgląd w czasie rzeczywistym. Zmiany mogą być recenzowane przez innych członków zespołu lub zaplanowane do automatycznej publikacji o konkretnej godzinie.

Dopiero w momencie publikacji cache odświeża się punktowo — tylko dla zmienionych stron i wersji językowych. Nowa wersja ląduje na produkcji w kilka sekund. Z kolei dla wydarzeń globalnych i webinarów godziny zapisujemy w jednej strefie czasowej, a przeglądarka odwiedzającego automatycznie przelicza je na jego czas lokalny.

Według danych Chrome User Experience Report LCP spadł z 4217 do 1961 milisekund, a CLS z 0,31 do 0,01. Nie ma za tym jednego triku, tylko suma wielu drobnych decyzji.

Duże znaczenie ma cache. Varnish serwuje większość stron bezpośrednio z pamięci podręcznej, więc przeglądarka od razu dostaje gotowy HTML. Druga kwestia to dbałość o wagę frontendu. Wszystkie obrazy przechodzą przez jeden komponent, który dobiera format i rozmiar do ekranu i rezerwuje dla nich miejsce w układzie, więc tekst się nie przesuwa. Domyślnie ładują się dopiero przy przewijaniu, z jednym świadomym wyjątkiem: obraz w hero, czyli pierwsze, co widzi użytkownik, ładuje się od razu. To on decyduje o LCP. Skoro to jeden komponent, nikt nie może o tym zapomnieć przy nowych sekcjach.

Ta sama zasada obowiązuje wszędzie: ładujemy tylko to, co jest potrzebne, i dopiero wtedy, gdy jest potrzebne. Wideo odtwarza się tylko wtedy, gdy jest visible na ekranie. Skrypty formularzy HubSpot trafiają wyłącznie na strony, które mają formularz. Google Tag Manager, baner cookies i narzędzia analityczne ładują się w ustalonej kolejności i dopiero po wyrażeniu zgody. To ważne zarówno dla wydajności, jak i dla zgodności z RODO.

Od pierwszego dnia pracowaliśmy jak jeden zintegrowany zespół, opierając się na jasnej komunikacji i szybkim przekazywaniu uwag. Daily służyło nam głównie do tego, żeby na bieżąco usuwać blokery i upewniać się, że idziemy w dobrym kierunku. Reszta pracy toczyła się naturalnie: przez bieżące rozmowy przy zadaniach, pair programming i dokładne code review.

Każda zmiana w kodzie automatycznie generowała własną, odizolowaną wersję podglądową strony. Dzięki temu design i redakcja ze Staffbase mogli na żywo sprawdzić nową funkcjonalność przed wdrożeniem na produkcję, bez czekania na oficjalne spotkania demonstracyjne.

Zależało nam też na tym, żeby po uruchomieniu platformy wewnętrzny zespół Staffbase mógł ją bezproblemowo rozwijać. Postawiliśmy na proste i powtarzalne standardy: jeśli każdy komponent jest zbudowany według tego samego wzorca, dodanie kolejnego bloku jest intuicyjne dla każdego dewelopera.

Przed napisaniem pierwszego szablonu spisałbym specyfikację wszystkich komponentów. Na początku budowaliśmy je w takiej kolejności, w jakiej pojawiały się potrzeby na makietach, i dopiero później ujednolicaliśmy kod. Gdybyśmy od razu ustalili wspólne elementy — takie jak odstępy, przyciski czy warianty kart — oszczędzilibyśmy sobie trochę poprawek.

Drugą rzeczą jest wczesne zaplanowanie analityki i zgód prywatności. Baner cookies, tag manager i narzędzia analityczne wpływają na szybkość strony i na to, co widzi użytkownik. U nas dochodziły one stopniowo w trakcie prac, a następnym razem wpisałbym je do backlogu od pierwszego sprintu.