Micro Frontend: 3 błędy, które rujnują wydajność Twojej aplikacji
Architektura micro frontendów brzmi kusząco: niezależne zespoły, szybsze wdrożenia, łatwiejsze skalowanie. W teorii – piękne. W praktyce – wielu programistów i CTO przekonuje się, że dzielenie frontendu na części to proszenie się o problemy z wydajnością, których nikt się nie spodziewał. Dlaczego? Bo zapominają, że przeglądarka to nie serwer, a użytkownik nie czeka na zgranie wszystkich klocków.
W JurskiTech widzieliśmy już projekty, w których mikro frontendy zamieniły szybką aplikację w wolny, rozlazły monolit – tyle że rozproszony. Oto 3 najczęstsze błędy, które widzę u klientów i w branży.
1. Współdzielenie stanu między mikro frontendami – czyli jak stworzyć wąskie gardło
Zespoły często decydują się na mikro frontendy, żeby odseparować logikę. Ale potem potrzebują, żeby dwa niezależne komponenty wymieniały dane – np. koszyk zakupowy i lista produktów. I tu zaczynają się schody.
Błąd: Używanie globalnego event busa lub współdzielonego obiektu window do synchronizacji stanu. To działa lokalnie, ale przy większej liczbie mikro frontendów zamienia się w labirynt zależności. Każda zmiana wymaga synchronizacji, co spowalnia renderowanie i utrudnia debugowanie. Poza tym tracisz izolację – główny atut mikro frontendów.
Przykład z życia: Klient z branży e-commerce miał osobne mikro frontendy dla wyszukiwarki, filtracji i listy produktów. Każdy z nich używał tego samego stanu koszyka przechowywanego w window. Po kilku miesiącach dodawania funkcji okazało się, że przy szybkim przełączaniu filtrów koszyk aktualizuje się z opóźnieniem, a czasem zawiera nieaktualne dane. Użytkownicy zgłaszali „znikające” produkty.
Rozwiązanie: Zamiast współdzielić stan, użyjcie wzorca „command pattern” z dedykowanym API do komunikacji. Albo – jeśli to możliwe – trzymajcie stan w jednym mikro frontendzie, a reszcie udostępniajcie tylko zdarzenia. Jeszcze lepiej: rozważcie, czy naprawdę potrzebujecie takiego poziomu współdzielenia. Czasem lepiej przeprojektować interfejs, żeby każdy mikro frontend był samowystarczalny.
2. Ładowanie wszystkiego naraz – czyli kosztowny brak strategii lazy loading
Każdy mikro frontend to osobny pakiet JavaScript i CSS. Jeśli wczytujesz je wszystkie na starcie, odwiedzający Twoją stronę czeka na ściągnięcie megabajtów kodu, zanim zobaczy cokolwiek. To szczególnie boli na pierwszych wizytach i na wolniejszych łączach.
Błąd: Brak podziału na route-based chunks. Wiele frameworków do mikro frontendów domyślnie ładuje wszystkie komponenty od razu. Deweloperzy często nie myślą o tym, że użytkownik może wejść tylko na stronę główną, a ściąga kod do panelu administracyjnego.
Przykład z życia: Jeden z startupów SaaSowych wdrożył mikro frontendy z użyciem Module Federation. Każdy zespół dodał swój moduł, ale nie skonfigurował lazy loadingu. W efekcie strona logowania ważyła ponad 3 MB JS. Czas do interakcji (TTI) sięgał 8 sekund na średnim sprzęcie. Potencjalni klienci rezygnowali, zanim w ogóle wpisali hasło.
Rozwiązanie: Wdróżcie lazy loading na poziomie routingu – każdy mikro frontend powinien ładować się tylko wtedy, gdy jest potrzebny. Użyjcie mechanizmów takich jak React.lazy, dynamic imports, czy wbudowane funkcje Webpack 5. Pamiętajcie też o preloadowaniu tych modułów, które są przewidywane – np. na podstawie zachowania użytkownika.
3. Ignorowanie skalowania CSS – czyli wojna stylów
Każdy mikro frontend ma swoje style. I każdy zespół pisze je po swojemu. Gdy łączysz je na jednej stronie, zaczyna się chaos: globalne klasy kolidują, selektory nadpisują się nawzajem, a responsywność nagle przestaje działać.
Błąd: Używanie globalnych arkuszy CSS lub frameworków jak Bootstrap bez scoped styles. Nawet jeśli użyjemy CSS Modules w każdym module, to konflikty mogą wystąpić na poziomie klas generowanych przez toolchain – np. gdy dwa moduły użyją tej samej nazwy komponentu.
Przykład z życia: Klient z platformą edukacyjną połączył trzy mikro frontendy: wideo, quizy i forum. Każdy z nich korzystał z tego samego zestawu ikon (Font Awesome), ale różne wersje. W przeglądarkach starszych typów (ale jeszcze używanych) ikony wyświetlały się jako kwadraciki. Użytkownicy myśleli, że strona jest zepsuta – wskaźnik odrzuceń wzrósł o 15%.
Rozwiązanie: Użyjcie CSS-in-JS (np. styled-components) albo przynajmniej Shadow DOM do izolacji stylów. Ustalcie wspólny system design (design system) z komponentami, które są udostępniane jako współdzielona biblioteka – każdy mikro frontend korzysta z tych samych wersji. Wprowadźcie automatyczne testy wizualne (np. Percy, Chromatic), żeby wykrywać regresje CSS.
Podsumowanie
Micro frontendy to potężne narzędzie, ale tylko jeśli pamiętasz, że to przede wszystkim inżynieria, a nie magiczny proszek. Unikaj współdzielenia stanu na siłę, zawsze wdrażaj lazy loading na poziomie tras i zadbaj o izolację oraz spójność stylów. W JurskiTech widzieliśmy, że te trzy punkty potrafią uratować projekt przed porażką – a czasem wystarczy jeden audyt, żeby wyłapać błędy, które spowalniają Twój biznes.
Jeśli zastanawiasz się, czy Twoja aplikacja nie ma problemów z wydajnością po wprowadzeniu mikro frontendów – daj znać. Sprawdzimy to w kilka godzin i powiemy, co poprawić.
