Tell me why, czyli krótko o tym, dlaczego szukaliśmy alternatywy
Czy frontend Magento 2 jest naprawdę taki zły? Problemy zauważyliśmy już przy pierwszym kontakcie z Magento 2 – zarówno od strony użytkownika sklepu, klienta, jak i developera.
Dla użytkowników niekorzystnie wyglądała pozornie w pełni załadowana strona, która wciąż “skacze”, ładując w tle kolejne komponenty. Sam checkout, który przecież pod względem UX jest jednym z najistotniejszych elementów sklepu internetowego, ukazywał się użytkownikowi z dużym opóźnieniem (szczególnie na mniej wydajnym sprzęcie).
Dla klientów, którym oddaliśmy gotowy projekt, niekorzystnie wyglądały dane otrzymywane od agencji SEO. Google twierdzi, że strona jest za wolna, a użytkownik musi czekać za długo, aby wejść w pierwszą interakcję (8.4s). Koszt optymalizacji domyślnego frontendu Magento 2 pod względem Core Web Vitals okazywał się zbyt wysoki, a korzyści wciąż niezadowalające.
Dla developerów nieatrakcyjnie prezentował się stack technologiczny. Nauka mało popularnych lub starych na rynku rozwiązań, które odchodzą w zapomnienie, demotywuje do pracy. Wystarczy spojrzeć na aktualny zestaw technologii:
▱ RequireJS - ostatnia wersja wydana pod koniec 2018 roku;
▱ Knockout - ostatnia wersja wydana pod koniec 2019 roku;
▱ jQuery - wspominamy z miłością i szacunkiem, ale czujemy, że na tym każdy frontend developer wolałby tę relację zakończyć.
To wszystko wyglądało na wyzwanie – przecież na pewno można to zoptymalizować, usprawnić. Nie spodziewaliśmy się jednak, że to będzie długa droga.
Ciekawostka: Backstreet Boys tak naprawdę śpiewali o frontendzie Magento
Własne optymalizacje
Pierwszym krokiem było usunięcie zbędnych plików JavaScript i wyłączenie modułów, których nie używamy. Kłopotliwe okazało się zarówno jedno, jak i drugie. Różne wtyczki dodawały skrypty na różne sposoby, a moduły – mimo że pozornie nie były wykorzystywane – okazywały się być dependencją innego, z którego korzystamy i ostatecznie nie można było ich wyłączyć. Pozostawało nadpisywanie wielu plików, co nie jest najlepszą praktyką. Zdołaliśmy usunąć niewiele zbędnych plików i efekty były nadal niezadowalające.
Rozwiązywanie problemów z wydajnością domyślnego frontendu Magento pochłaniało coraz więcej czasu i zwiększało koszty projektu. Postanowiliśmy więc zastosować inne podejście.
Pracowaliśmy również z takimi rozwiązaniami jak MageSuite, który był bardzo dobrą odpowiedzią dla Magento PageBuilder dostępnym tylko w wersji Magento Commerce. W zestawie z MageSuitem postanowiliśmy skorzystać z MagePacka – alternatywnego rozwiązania do budowania plików JS. Liczyliśmy na rozwiązanie wszystkich bolączek związanych z domyślnym frontem, ale pomimo ogromu prac twórców tego rozwiązania i ono niosło ze sobą pewne trudności, których nie mieliśmy wcześniej – okazjonalne problemy z budowaniem skryptów JS i wciąż niezadowalające nas rezultaty.
W poszukiwaniu lepszej drogi
Nie tylko my borykamy się z problemem wydajności frontendu, dlatego w ekosystemie Magento można znaleźć wiele alternatywnych rozwiązań frontendowych. Część z nich to rozwiązania headless, ale czy jest to na pewno jedyny rozsądny kierunek? Nie chcemy w tym artykule nikogo ewangelizować w temacie, które rozwiązanie jest najlepsze, ponieważ stronimy od hype i jesteśmy świadomi, że za wybór technologii odpowiada wiele czynników. Chcemy przedstawić naszą historię z frontendem Magento 2 i wybory, jakich dokonaliśmy.
Mieliśmy również okazję uczestniczyć w gorącej dyskusji na Poznańskim Magento MeetUp, gdzie dyskutowaliśmy nad rozwiązaniami takimi jak Vue Storefront 1, ScandiPWA, Falcon czy PWA Studio i choć każdy z obecnych na meetupie obrał wtedy jakąś drogę, to jednomyślnie stwierdziliśmy, że żadne z obecnych rozwiązań (na rok 2019) nie było gotowe w takim stopniu, jak byśmy tego oczekiwali.
Co z PWA Studio?
W przypadku projektu, w którym wymagane było rozwiązanie headless, szukaliśmy najlepszego podejścia pod względem PWA. Wówczas wybraliśmy "najbardziej pewną drogę", czyli oficjalny produkt Magento. Zaczęliśmy więc projekt PWA Studio w wersji 4 (dziś aktualna wersja to 12). Sama technologia, o jaką jest oparte PWA Studio – React, nie stanowiła dla nas problemu, natomiast okres rozwoju produktu był mocno gorący i co kilka miesięcy aktualizowaliśmy projekt o nową wersję, co było dość utrudnionym procesem w kontekście śledzenia wszystkich breaking changes. Często praca w projekcie PWA Studio wiązała się z debugowaniem błędów i monitorowaniem zmian, aby wiedzieć, co zostanie dostarczone przez PWA Studio, a co powinniśmy obsłużyć sami.
PWA Studio a Server-Side Rendering
O ile technologicznie to wszystko nie było dla nas aż tak dużym problemem, to jest jedna rzecz, której do dziś PWA Studio nie jest w stanie przeskoczyć – kompleksowy Server-Side Rendering (SSR). Aby jednostronicowa aplikacja (SPA) była zoptymalizowana pod SEO, renderowanie po stronie serwera jest koniecznością, w przeciwnym razie wyszukiwarki nie są w stanie odczytać treści tak, jak widzi je użytkownik. W początkowej fazie projektu uczestniczyliśmy również w meetupie PWA Studio realizowanym przez Adobe, gdzie zespół developerski Magento przedstawił możliwe rozwiązania problemu SSR. Wiedzieliśmy wtedy, że jest to potencjalny problem, przed którym musimy się zabezpieczyć, aby iść dalej. Pomysłem na Server-Side Rendering miał być osobny serwis (SeoSnap) do renderowania pełnych źródeł stron, na który kierowany będzie GoogleBot. Usługa ta wykorzystuje narzędzie od Google, jakim jest Rendertron. W naszym odczuciu rozwiązanie to jest niedopracowane, ponieważ strona renderowana przez SeoSnap różni się od tego, co użytkownicy widzą np. na swoich telefonach.
PWA Studio a Core Web Vitals
Do braku pełnego SSR dochodzi problem ze zmianami Core Web Vitals (CWV). Trudno uzyskać dobre wyniki w audycie Google, jeżeli cała strona jest renderowana po stronie przeglądarki. Mocny wpływ na metryki CWV np. na LCP (Largest Contentful Paint) ma sposób implementacji, jakim jest SPA, czyli jednostronicowa aplikacja (ang. Single Page Application). To powoduje, że przeglądarka musi odebrać wymagany content z API w celu wyrenderowania strony. Z kolei API powinno odpowiadać z minimalnym opóźnieniem, aby zapewnić dobry performance ładowania się takich stron. Warto w tym miejscu wspomnieć, że domyślne GraphQL API w Magento nie należy do najszybszych i konieczne jest zadbanie o warstwę cache. Dodatkowo PWA Studio do wyrenderowania np. strony kategorii odpytuje API aż 25 razy, co wymaga około 2315ms. Każde kolejne pobranie innego typu strony wymaga minimum 2 zapytań – jedno o typ strony, który chcemy pobrać (np. kategoria), a dopiero potem możemy odpytać API o content dla danej kategorii. To wszystko wymaga czasu, którego nie mamy zbyt dużo w przypadku audytu Google PageSpeed Insight (przykładowo 2.5 sekundy, by nasza strona spełniła metrykę LCP).
PWA Studio – wnioski na przyszłość
Wybraliśmy PWA Studio dla szybszego frontendu. O ile dzięki dodatkowej optymalizacji i cachowaniu zapytań API, frontend ten jest naprawdę szybki dla użytkownika końcowego, to wpadamy w tę samą pułapkę, jak w przypadku domyślnego szablonu Magento i jego audytów np. Core Web Vitals – bardzo kosztowna optymalizacja frontendu pod CWV.
Jest wiele czynników wpływających na ogólny performance projektu opartego o PWA Studio. Musimy pamiętać, że frontend jest tylko jednym kawałkiem układanki i nie rozwiąże on problemów wolnego API.
W kolejnym projekcie, gdzie headless nie był wymagany w warstwie frontendu, wdrożyliśmy Hyvä Themes.
Co to jest Hyvä?
Świadoma część społeczności zna ten termin bardzo dobrze – Hyvä to płatna skórka dla Magento. Odchodzi ona zupełnie od podejścia frontendowego zastosowanego w domyślnej skórce, z której nie zostało nic. Zamiast tego stawia na nowoczesne rozwiązania w prostej formie. Skrypty JavaScript są ładowane tylko tam, gdzie są rzeczywiście wymagane, a plik CSS zawiera tylko deklaracje wykorzystywane na stronie.
Dzięki Hyvä Themes dostajemy bardzo dobry performance frontendu już na początku projektu, co jest miłą odmianą dla domyślnego rozwiązania Magento. To, jak szybko będzie ładować się nasz e-commerce i jakie wyniki Core Web Vitals uzyskamy, będzie zależeć wyłącznie od nas.
Magento Luma i Hyvä – porównanie pod kątem wydajności
Poniżej przedstawiamy Google PageSpeed Insights dla katalogu produktów Magento. Musimy nadmienić, że jeszcze 2-3 lata temu wyniki domyślnej skórki Magento były w naszych testach gorsze o niemal połowę.
Jesteśmy pełni podziwu dla ogromu pracy, jaką wykonali twórcy Hyvä. Nie uważamy, że napisanie nowego rozwiązania (np. headless) oznacza mniej wysiłku, ale doprowadzenie istniejącego produktu, z którym mało kto chce pracować, do stanu, gdzie developer znów czuje frajdę, to nie lada wyczyn! Stale rosnąca społeczność Hyvy pomaga nam utwierdzić się w przekonaniu o słuszności tej decyzji. Większość popularnych rozszerzeń Magento posiada już szablony kompatybilne z Hyvä, opracowane przez społeczność.
Dlaczego Hyvä jest szybsza?
Zaczynając projekt z Hyvä, mamy bardzo dobry punkt startu, jeżeli chodzi liczbę potrzebnych do wyrenderowania strony blokujących zapytań – czyli potrzebnego kodu CSS/JS.
W przypadku Magento Luma normą jest liczba ~200 plików, a Hyvä potrzebuje zaledwie 2 pliki. Jedno zapytanie dla biblioteki CSS (Taiwlind CSS), drugie dla biblioteki JS (Alpine.js). Do wyrenderowania strony przeglądarka użytkownika musi pobrać zaledwie 27.7 kB dodatkowego kodu. Jest to wspaniały wynik, który trudno uzyskać nawet przy rozwiązaniach headless.
Tailwind CSS i Alpine.js dla Hyvä Themes
Należy wspomnieć, że im bardziej zaawansowany wizualnie staje się nasz e-commerce, tym większy będzie kod wynikowy CSS, lecz nie będzie on rosnąć tak szybko jak w klasycznym podejściu, ponieważ został wykorzystany tutaj Tailwind CSS, który zajmuje się optymalizacją pliku wynikowego. Podana technologia wzbudza wiele emocji i skrajnych opinii, ale więcej na ten temat opowiemy w kolejnym – bardziej technicznym – artykule.
Za warstwę interakcji odpowiada biblioteka Alpine.js, której rozmiar to 8.9 kB (gzip). Nie znajdziemy więcej kodu JavaScript w podejściu preferowanym przez Hyvä, gdyż kod ten znajduje się blisko szablonów, a dokładnie wewnątrz (inline JavaScript), co może być trochę kontrowersyjne, jeżeli mówimy o dobrych praktykach.
Tailwind CSS i Alpine.js to proste i lekkie technologie, co sprawia, że developer experience jest znacznie przyjemniejszy, a to przekłada się również na prostsze wdrożenie nowych developerów w stack Magento oparty na szablonie Hyvä. Wszyscy wiemy, jak trudno jest znaleźć frontend developera dla Magento.
Poza tymi dwoma bibliotekami, nie uświadczymy żadnych smutnych i przestarzałych rozwiązań takich jak RequireJS, Knockout czy jQuery UI.
Jakie funkcjonalności Magento wspiera Hyvä?
Aby domyślne funkcjonalności Magento mogły poprawnie działać w obrębie aktualnych szablonów PHTML, twórcy Hyvä musieli przepisać je ze starych technologii na nowe, a to wymaga czasu. W efekcie tego część bardziej zaawansowanych funkcjonalności np. dostępnych dla Magento Commerce może nie być wspierana. Przy naszym pierwszym wdrożeniu Hyvä pracowaliśmy z projektem typu B2B, gdzie część tych funkcjonalności musieliśmy zaimplementować sami. Ten sam proces dotyczy płatnych wtyczek, które dostarczają nowe funkcjonalności oparte o domyślne technologie Magento. Na szczęście Hyvä wspiera większość domyślnych funkcjonalności i pokaźną liczbę wtyczek. Mało które customowe rozwiązanie frontendowe dla Magento może pochwalić się takim wsparciem.
Ważną kwestią, którą należy poruszyć w kontekście dostarczonych przez szablon Hyvä funkcjonalności, jest brak wsparcia dla checkoutu. W tym przypadku możemy zadowolić się domyślnym checkoutem Magento (tak, wiemy…) lub skorzystać z darmowej wtyczki Hyvä Checkout, bazującej na technologii React.
Jeżeli interesuje Cię, jakie domyślne funkcjonalności Magento wspiera Hyvä, możesz sprawdzić feature matrix ⇨ https://Hyvä.io/Hyvä-themes-feature-matrix
Jeżeli chciałbyś dowiedzieć się, jakie wtyczki wspiera Hyvä, sprawdź module tracker ⇨ https://gitlab.Hyvä.io/Hyvä-public/module-tracker/
Podsumowanie
Uważamy, że szablon Hyvä jest dobrą i tańszą w implementacji alternatywą dla nowych rozwiązań headless. Dzięki temu mamy bardzo dobry performance, łatwiejszy technologicznie stack frontendowy, co przekłada się na szybsze wdrożenie nowych developerów. Nie wspomnieliśmy nic o kosztach, ponieważ z perspektywy świadomych Magento developerów, którzy wiedzą, ile czasu wymaga optymalizacja lub przepisanie frontendu Magento, koszt ten wydaje się naprawdę symboliczny – 1000 €. Dlatego też wprowadzamy projekty oparte o Hyvä do portfolio naszych produktów, a Was zachęcamy do sprawdzenia szablonu na żywo i zapoznania się z oficjalną stroną.
Jako Macopedia nie tylko wdrażamy szablony Hyvä, ale również wspieramy projekt i kontrybujemy. Dla nowej wersji dostarczamy zaawansowane walidacje formularzy.
Jeśli chciałbyś dowiedzieć się więcej na temat Hyvä, sprawdź nasze case study z wdrożenia Magento 2 w firmie INOXA lub śledź na bieżąco naszego bloga, gdzie już niedługo pojawią się kolejne materiały.