Hyvä dla Magento

Problem nie zawsze brzmi „mamy słaby wynik PageSpeed”.

Bardziej istotne jest to, że frontend z czasem stał się hamulcem dalszego rozwoju sklepu. Kolejne zmiany są trudniejsze, kod coraz bardziej złożony, wydajność słaba, a planowany redesign oznacza dokładanie kolejnych warstw do rozwiązania, które i tak wymaga modernizacji.

W nowych wdrożeniach Magento domyślnie rekomendujemy Hyvä. Przebudowujemy na Hyvä również istniejące storefronty, w których stara warstwa frontendowa zaczęła ograniczać dalszy rozwój.

Możemy przeprowadzić cały proces: od analizy i UX/UI po development, checkout, testy i uruchomienie.

Bezpłatna rozmowa, 30-60 minut. Omówimy obecny frontend, wyniki wydajności i ograniczenia wdrożenia. Wstępnie ocenimy, czy Hyvä jest właściwym kierunkiem i jaki zakres analizy będzie potrzebny.

Sygnały

Kiedy frontend zaczyna być ograniczeniem

Problemy zazwyczaj pojawiają się stopniowo.

  • Sklep działa wolno mimo poprawnego czasu odpowiedzi backendu.
  • Z pozoru niewielka zmiana wymaga ingerencji w kilka warstw kodu.
  • Kolejne customizacje zwiększają koszt utrzymania.
  • Wyniki narzędzi Google pozostają słabe mimo kolejnych poprawek.

Częstym wspólnym mianownikiem jest frontend rozwijany przez lata na starszym stacku i obudowany customowym kodem.

W takim momencie kolejne lokalne poprawki mogą przestać być dobrą inwestycją. Warto sprawdzić, czy bardziej uzasadniona nie będzie przebudowa warstwy prezentacji.

Fundament

Co zmienia Hyvä

Hyvä daje prostszy i lżejszy fundament dla frontendu Magento.

Prostszy rozwój

Mniejsza liczba warstw i zależności upraszcza pracę przy kolejnych zmianach. Dzięki temu frontend może być łatwiejszy do utrzymania i bardziej przewidywalny w dalszym rozwoju.

Mniejszy narzut

Hyvä znacząco ogranicza narzut charakterystyczny dla starszej warstwy frontendowej Magento.

Lepsza baza

To daje lepszą bazę do pracy nad Core Web Vitals i rzeczywistą szybkością działania interfejsu.

Nie oznacza jednak gwarancji konkretnego wyniku - na efekt wpływają również backend, obrazy, skrypty zewnętrzne, sposób implementacji i infrastruktura.

Przebudowa jest dobrym momentem, żeby nie przenosić dalej wszystkich historycznych customizacji.

Część z nich nadal będzie potrzebna i trzeba będzie je dostosować do Hyvä. Inne można uprościć albo całkowicie usunąć.

Granice technologii

Czego Hyvä nie naprawia

Hyvä rozwiązuje problem warstwy frontendowej.

Nie przyspieszy wolnej bazy danych, nie naprawi błędnych integracji, problemów z indeksowaniem, OpenSearch czy niedopasowaną infrastrukturą.

Jeżeli backend długo generuje odpowiedź, lekki frontend nadal będzie na nią czekał.

Dlatego przed rekomendacją przebudowy warto sprawdzić, gdzie rzeczywiście znajduje się ograniczenie.

Jeżeli problem leży po stronie backendu, właściwym punktem wyjścia będzie Optymalizacja wydajności Magento →

Scenariusze

Nowe wdrożenie albo przebudowa istniejącego Magento

Pracujemy z Hyvä w dwóch głównych scenariuszach.

Hyvä jest naszym domyślnym wyborem dla nowych storefrontów Magento

Dzięki temu nowa platforma od początku powstaje na frontendzie, który ma być dalej rozwijany, zamiast rozpoczynać projekt od starszej warstwy technologicznej.

Backend Magento może pozostać, a przebudowie podlega warstwa prezentacji

To pozwala usunąć problematyczny frontend bez konieczności budowania całej platformy od zera.

Taki projekt wymaga jednak wcześniejszego ustalenia, co z obecnego rozwiązania rzeczywiście warto przenieść.

Legacy

Nie kopiujemy starego frontendu 1:1

Przebudowa na Hyvä nie powinna oznaczać automatycznego odtworzenia wszystkich funkcji i customizacji starego sklepu.

Przed rozpoczęciem developmentu ustalamy:

  • co jest rzeczywiście wykorzystywane,
  • które elementy nadal mają uzasadnienie biznesowe,
  • co można uprościć,
  • które rozwiązania powstały wyłącznie ze względu na ograniczenia wcześniejszego frontendu.

Dzięki temu nowa warstwa nie zaczyna życia z długiem odziedziczonym po poprzednim rozwiązaniu.

UX/UI

UX/UI może być częścią projektu

Klient nie musi przychodzić z gotowym designem.

Możemy przeprowadzić pełny proces UX/UI i przygotować projekt interfejsu, a następnie wdrożyć go na Hyvä.

Możemy również pracować z projektem dostarczonym przez zespół klienta lub inną agencję.

Przejście na Hyvä jest często dobrym momentem na redesign, ale redesign nie jest obowiązkowym elementem przebudowy technologicznej.

Checkout

Hyvä i checkout

Checkout traktujemy jako część całego doświadczenia użytkownika, a nie osobny produkt przyklejony do storefrontu.

W ramach projektu możemy objąć również jego UX i implementację odpowiedniego rozwiązania checkoutowego w ekosystemie Hyvä.

To szczególnie istotne wtedy, gdy checkout starego sklepu jest jednym z obszarów wymagających największych zmian.

Kompatybilność

Customowe moduły i kompatybilność

Zmiana frontendu Magento nie kończy się na instalacji nowego theme.

Trzeba sprawdzić wszystkie elementy posiadające własną warstwę frontendową:

  • moduły Magento,
  • customowe funkcje,
  • płatności,
  • dostawy,
  • analitykę,
  • narzędzia marketingowe,
  • integracje działające w przeglądarce.

Część rozszerzeń ma gotową kompatybilność z Hyvä. Inne wymagają dostosowania, a w niektórych przypadkach bardziej sensowne jest zastąpienie starego modułu prostszym rozwiązaniem.

Dlatego kompatybilność rozszerzeń uwzględniamy podczas analizy zakresu, a nie dopiero pod koniec developmentu.

Proces

Jak wygląda projekt Hyvä

Zakres może obejmować analizę istniejącego frontendu lub discovery nowego sklepu, UX/UI, development Hyvä, dostosowanie modułów i customowych funkcjonalności, checkout, testy, uruchomienie i stabilizację.

  1. 01

    Analiza

    Analiza istniejącego frontendu lub discovery nowego sklepu.

  2. 02

    UX/UI

    Projekt doświadczenia użytkownika i interfejsu.

  3. 03

    Development

    Implementacja frontendu na Hyvä.

  4. 04

    Dostosowanie

    Dostosowanie modułów i customowych funkcjonalności.

  5. 05

    Checkout i testy

    Implementacja checkoutu oraz testy całego rozwiązania.

  6. 06

    Uruchomienie

    Uruchomienie i stabilizacja nowej warstwy frontendowej.

Nie wszystkie prace muszą być wykonywane sekwencyjnie. UX/UI, development wybranych elementów i prace integracyjne mogą częściowo przebiegać równolegle.

Kontekst projektu

Hyvä jako element większej zmiany

Przebudowa frontendu nie zawsze jest samodzielnym projektem.

Hyvä może być częścią:

  • nowego wdrożenia Magento,
  • redesignu,
  • projektu optymalizacji,
  • ratowania projektu,
  • szerszej modernizacji istniejącego sklepu.

Najważniejsze jest to, jaki problem chcemy rozwiązać.

Jeżeli obecny frontend działa dobrze, jest łatwy w utrzymaniu, a potrzebna jest jedynie kosmetyczna zmiana wyglądu, wymiana technologii może być niepotrzebnym kosztem.

Velocity

Dlaczego Velocity

Hyvä jest naszym domyślnym kierunkiem dla nowych wdrożeń Magento.

Przy przebudowie istniejących sklepów istotne jest jednak również to, że pracujemy nie tylko na warstwie frontendowej. Rozumiemy backend Magento, bazę, OpenSearch, integracje i infrastrukturę.

Dzięki temu możemy najpierw ocenić, czy problem faktycznie leży we frontendzie, zamiast zakładać, że Hyvä jest odpowiedzią na każdy problem z wydajnością.

Możemy również pozostać przy platformie po uruchomieniu i odpowiadać za jej dalszy rozwój oraz utrzymanie.

Właściwy kierunek

Kiedy Hyvä nie jest właściwym rozwiązaniem

Rescue Magento

Jeżeli cała platforma jest niestabilna, błędy wracają i trudno określić jej stan techniczny, pierwszym krokiem może być przejęcie i stabilizacja projektu Magento.

Rescue Magento →

Zmiana wyglądu

Jeżeli chodzi wyłącznie o nowy wygląd, a obecny frontend jest zdrowy i utrzymywalny, zmiana technologii może nie mieć ekonomicznego uzasadnienia. Nie rekomendujemy też Hyvä wyłącznie po to, żeby osiągnąć konkretną liczbę w PageSpeed. Najpierw trzeba ustalić, co rzeczywiście ogranicza sklep.

Pytania

FAQ

VLCT

Jeżeli istotna część problemu leży w warstwie frontendowej, Hyvä może dać dużą poprawę. Nie naprawi jednak wolnej bazy danych, indeksowania, OpenSearch ani integracji. Przed rekomendacją warto ustalić, gdzie rzeczywiście tracony jest czas.

VLCT

Hyvä daje lżejszy fundament frontendowy i ułatwia pracę nad Core Web Vitals, ale nie gwarantuje konkretnego wyniku. Wąskim gardłem nadal mogą być backend, obrazy, skrypty zewnętrzne, wyszukiwarka lub infrastruktura.

VLCT

Nie. Możemy zachować obecny kierunek wizualny albo potraktować projekt jako okazję do redesignu.

VLCT

Część ma gotową kompatybilność z Hyvä, część wymaga dostosowania, a czasami bardziej sensowne jest zastąpienie starego rozszerzenia innym rozwiązaniem. Sprawdzamy to podczas analizy zakresu.

VLCT

Tak. Jeżeli backend i pozostała architektura są w dobrym stanie, można pozostawić istniejącą platformę i przebudować warstwę frontendową.

VLCT

Tak. Możemy przygotować pełny UX/UI albo wdrożyć projekt dostarczony przez klienta.

VLCT

Tak. Traktujemy checkout jako część frontendu i ścieżki zakupowej, dlatego może być projektowany i wdrażany razem z pozostałą warstwą Hyvä.

VLCT

Tak. Można na nim budować również interfejsy dla procesów B2B, w tym szybkie zamówienia, konta firmowe i inne customowe procesy. Więcej: E-commerce B2B →