Czy z szablonem Hyvä Magento 2 będzie zawsze działać szybciej niż z jakimkolwiek innym szablonem?

Wyobraź sobie dwa sklepy Magento. Pierwszy korzysta z Hyvä, ale na wejściu uruchamia kilkanaście narzędzi marketingowych, pobiera wielkie zdjęcia i za każdym razem generuje stronę od nowa. Drugi ma inny, starannie zoptymalizowany motyw, sprawny cache i tylko te skrypty, których potrzebuje klient.

Który będzie szybszy? Nazwa szablonu nie wystarczy, żeby odpowiedzieć.

Hyvä daje Magento bardzo dobry punkt wyjścia do budowy szybkiego sklepu. Nie daje jednak bezwarunkowej przewagi nad każdym innym wdrożeniem. Wynik zależy od całej drogi między kliknięciem linku a chwilą, w której klient widzi produkt i może go kupić.

Dlatego wdrożenie Hyvä warto połączyć z przeglądem serwera, modułów, obrazów i projektu interfejsu. Wtedy można pracować nad ambitnym celem: 95–100 punktów w Google PageSpeed Insights, przy zachowaniu funkcji potrzebnych do sprzedaży.

Co właściwie oznacza wynik 95–100 w PageSpeed?

Potocznie mówimy o „100% w PageSpeed”, ale narzędzie prezentuje punkty w skali od 0 do 100. W części opartej na Lighthouse ocenia cztery różne obszary:

Te oceny nie zastępują się nawzajem. Szybki sklep może mieć nieczytelne przyciski. Poprawny technicznie sklep może pobierać zbyt dużo JavaScriptu. Lighthouse jest narzędziem diagnostycznym, a zakres jego audytów nie obejmuje całej jakości sklepu. Opis Lighthouse.

Wynik Performance pochodzi z pomiaru laboratoryjnego i może zmieniać się między próbami. PageSpeed pokazuje również, jeśli są dostępne, dane rzeczywistych użytkowników z CrUX, zbierane w ruchomym okresie 28 dni. Nowe wdrożenie nie zmieni od razu całego tego zestawu danych. Jak działa PageSpeed Insights.

W praktyce potrzebujemy dwóch celów: powtarzalnie dobrych testów oraz dobrych doświadczeń klientów. Dla Core Web Vitals oznacza to:

• LCP do 2,5 s — szybkie pojawienie się największego elementu w widocznym obszarze;
• INP do 200 ms — sprawną reakcję na interakcje;
• CLS do 0,1 — stabilny układ strony.

Te progi ocenia się na 75. percentylu, osobno dla urządzeń mobilnych i komputerów. Standardowy test ładowania Lighthouse nie mierzy INP; do diagnozy blokowania przeglądarki wykorzystuje m.in. TBT. Niski TBT nie jest automatycznym potwierdzeniem dobrego INP. Core Web Vitals.

Jak Hyvä pomaga przyspieszyć Magento?

Hyvä ogranicza ciężar frontendu względem standardowej Lumy. Wykorzystuje Alpine.js do interakcji oraz Tailwind CSS do stylowania. Mniej kodu do pobrania i wykonania daje przeglądarce więcej miejsca na szybkie pokazanie oferty. Dokumentacja Hyvä wskazuje ograniczenie JavaScriptu i CSS jako ważną część tej architektury. Wydajność Hyvä.

Korzyść łatwo jednak zmniejszyć. Wystarczy do lekkiego frontendu dołożyć rozbudowany slider, czat, kilka trackerów i moduły przenoszące stare zależności z poprzedniego motywu.

Hyvä nie naprawi również wolnego zapytania do bazy, niedziałającego cache ani serwera zajętego importem. Dlatego pytanie przed wdrożeniem powinno brzmieć: co dziś opóźnia zakup i które z tych problemów rozwiąże zmiana frontendu?

1. Serwer: nginx i Varnish muszą wykonywać właściwą pracę

Zanim przeglądarka pokaże produkt, musi dostać dokument HTML. Jeśli długo czeka na pierwszy bajt odpowiedzi, nawet lekki motyw zaczyna z opóźnieniem.

Nginx: sprawne dostarczanie zasobów

W typowej architekturze Magento nginx obsługuje m.in. HTTPS, pliki statyczne i przekazywanie żądań do kolejnych usług. Warto sprawdzić kompresję tekstowych odpowiedzi, HTTP/2 oraz nagłówki cache dla wersjonowanych plików CSS i JS. Adobe udostępnia przykładową konfigurację nginx jako punkt wyjścia dla wdrożenia z Varnish. Konfiguracja Varnish w Adobe Commerce.

Nie należy nadawać wszystkim odpowiedziom identycznego czasu przechowywania. Wersjonowany arkusz CSS może być długo używany z pamięci przeglądarki. Cena, zawartość koszyka i odpowiedź dotycząca zalogowanego klienta wymagają innego traktowania.

Jeżeli serwer dobiera WebP do nagłówka Accept, trzeba sprawdzić również klucz cache i nagłówek Vary: Accept. Przeglądarka i pośrednie warstwy cache muszą odróżniać warianty obrazu.

Varnish: sprawdzamy trafienia w cache, a nie samo zainstalowanie usługi

Varnish pozwala obsługiwać publiczne strony z cache bez ponownego wykonywania całej pracy przez Magento. Adobe rekomenduje jego użycie w środowisku produkcyjnym. Zarządzanie cache Magento.

Praktyczny test jest prosty: otwieramy ten sam publiczny adres kilka razy i sprawdzamy, czy po pierwszej odpowiedzi pojawiają się trafienia HIT. Następnie porównujemy czas odpowiedzi z cache i czas wygenerowania strony przy MISS.

Jeżeli popularna kategoria stale omija cache, trzeba znaleźć przyczynę: konfigurację, cookies, parametry adresu, personalizację lub sposób działania modułu. Kupienie większego serwera może wtedy tylko zamaskować problem.

Ważna jest też poprawność. Cache nie może udostępnić koszyka ani danych jednego klienta innemu użytkownikowi. Należy przetestować warianty sklepu, waluty i grup klientów, a także odświeżanie treści po zmianie produktu. Szybka, ale nieaktualna cena nie jest sukcesem optymalizacji.

Poza nginx i Varnish sprawdzamy PHP-FPM, OPcache, backend cache zgodny z wersją Magento, bazę danych, cron i indeksowanie. Liczba procesów PHP powinna wynikać z dostępnej pamięci i rzeczywistego obciążenia. Zwiększanie jej bez pomiaru potrafi pogorszyć sytuację.

2. Moduły pod Hyvä: zgodność to dopiero początek

Moduł może działać poprawnie z Hyvä i nadal wykonywać zbyt dużo pracy przy wejściu na stronę. Dobra optymalizacja obejmuje więc zarówno funkcję, jak i koszt jej uruchomienia.

W kowal.store dostosowujemy nasze moduły do Hyvä i rozwijamy je z myślą o zachowaniu wydajności tego motywu po instalacji. Dbamy o to, aby nowe funkcje nie obciążały niepotrzebnie frontendu — przez ograniczanie zależności oraz odpowiedni sposób ładowania JavaScriptu i CSS. Zobacz nasze moduły Magento 2 i wybierz rozszerzenia do swojego sklepu. Efekt konkretnego wdrożenia warto potwierdzić pomiarem, ponieważ zależy również od konfiguracji i pozostałych integracji.

Weźmy czat. Klient przeglądający kategorię potrzebuje na początku przycisku otwierającego rozmowę. Rozbudowany interfejs czatu i jego biblioteki mogą zostać pobrane przy otwarciu. Podobnie pełne podpowiedzi wyszukiwarki można przygotować przy wejściu w pole wyszukiwania, pozostawiając od razu widoczny i działający formularz.

Takie podejście opisuje również Hyvä w zaleceniach dotyczących ładowania zewnętrznego JavaScriptu.

defer, async i opóźnienie komponentu to różne rzeczy

defer pozwala wykonywać zewnętrzny klasyczny skrypt po przetworzeniu dokumentu i zachować kolejność skryptów tego typu. async uruchamia skrypt, gdy jest gotowy, bez gwarancji kolejności względem innych. Żaden z tych atrybutów sam w sobie nie oznacza, że plik zostanie pobrany dopiero po kliknięciu.

Hyvä udostępnia również x-defer, którym można opóźnić inicjalizację komponentu Alpine, np. do zbliżenia się do widocznego obszaru. To nie jest automatyczne odroczenie pobierania wszystkich jego plików. Trzeba też pamiętać o zdarzeniach, które komponent może przegapić przed inicjalizacją, np. związanych z danymi klienta. Dokumentacja x-defer.

Zmiany należy sprawdzić na koszyku, filtrach, formularzach i zdarzeniach analitycznych. Sama obecność atrybutu defer nie dowodzi, że moduł jest dobrze zoptymalizowany.

CSS: potrzebny wygląd powinien być gotowy przed pierwszym renderowaniem

Style nagłówka, listy produktów i mobilnego układu są potrzebne od początku. Ich zbyt późne wczytanie może spowodować miganie strony i przesuwanie elementów. Jednocześnie kategoria produktów nie musi pobierać wszystkich stylów każdego zainstalowanego modułu.

Warto ograniczyć globalne arkusze, usunąć pozostałości starego motywu i sprawdzić produkcyjny build Tailwinda. Przy klasach tworzonych dynamicznie trzeba zadbać, żeby potrzebne reguły znalazły się w wynikowym CSS. Krytyczny CSS osadzony w HTML może pomóc, ale wymaga utrzymania i testów; nie powinien być pierwszą odpowiedzią na każdy problem. Zasoby blokujące renderowanie.

Analityka i dane SEO również mają swój koszt

Pracując nad optymalizacją sklepu na Magento 2, sprawdziliśmy obciążenie analityką na stronie kategorii. GTM i gtag odpowiadały za około 304 KB, czyli 44% transferu zarejestrowanego w pierwszym pomiarze mobilnym. To dobry powód, żeby przejrzeć tagi i wyzwalacze. Nie oznacza to, że należy bez namysłu opóźnić całą analitykę: taka zmiana może zmienić liczbę rejestrowanych wizyt i zdarzeń.

Warto zajrzeć też do samego HTML. Rozbudowane dane JSON-LD, powielone informacje o produktach i konfiguracje modułów zwiększają odpowiedź serwera. JSON-LD nie wykonuje się jak zwykły program JavaScript, ale nadal musi zostać przesłany. Dane strukturalne kategorii powinny odpowiadać widocznej liście, jej paginacji i kolejności.

3. Zdjęcia: liczą się format, rozmiar i moment pobrania

Zdjęcie źródłowe o szerokości kilku tysięcy pikseli nie powinno bez potrzeby trafiać do małego kafelka produktu. Przygotowujemy warianty dopasowane do rozmiaru wyświetlania i gęstości ekranu, a srcset i sizes pomagają przeglądarce wybrać właściwy plik. WebP lub AVIF warto porównać pod względem jakości i wagi na konkretnych zdjęciach.

Najważniejsze rozróżnienie dotyczy obrazów widocznych od razu i tych znajdujących się niżej. Obraz będący LCP powinien być łatwy do odkrycia w HTML, bez loading="lazy"; uzasadnione może być fetchpriority="high". Obrazy poza pierwszym ekranem są dobrymi kandydatami do lazy loadingu. Wymiary lub proporcje rezerwują im miejsce w układzie. Obrazy responsywne.

Nie ustawiamy jednak wysokiego priorytetu każdemu zdjęciu. Przeglądarka potrzebuje informacji, co jest naprawdę najważniejsze. Fetch Priority.

Sprawdzamy także banery CMS, logo, favicon, miniatury filmów i grafiki popupów. Optymalizacja musi obejmować proces dodawania nowych plików, inaczej kolejna kampania przywróci ciężkie obrazy.

Sam adres kończący się na .png nie przesądza, co pobiera przeglądarka. Serwer może pod tym adresem dostarczać WebP. Weryfikujemy Content-Type i transfer w zakładce Network.

4. Kolorystyka: jej największy wpływ zobaczysz w dostępności

Zmiana niebieskiego przycisku na zielony nie przyspieszy Magento. Kolor ma jednak duże znaczenie dla czytelności i wyniku Accessibility.

Najczęściej problemy powodują jasnoszare opisy, pastelowe przyciski z białym tekstem, etykiety promocji i tekst na zdjęciach. Zgodnie z WCAG kontrast zwykłego tekstu powinien wynosić co najmniej 4,5:1, a dużego tekstu 3:1. Duży tekst oznacza co najmniej 18 pt, czyli około 24 px, albo 14 pt przy pogrubieniu, czyli około 18,7 px. Wymagania kontrastu tekstu.

Dla istotnych wizualnych elementów kontrolek i oznaczeń ich stanu obowiązuje również wymaganie kontrastu 3:1 względem sąsiadujących kolorów, z wyjątkami opisanymi w standardzie. Kontrast elementów nietekstowych.

Paletę warto definiować centralnie, np. przez zmienne CSS lub konfigurację modułu kolorystyki. Dzięki temu zmiana koloru tekstu czy przycisków obejmuje cały sklep. Trzeba sprawdzić również stany hover, focus, błędy formularzy i wybrane filtry. Czerwony obrys nie powinien być jedyną informacją, że pole zawiera błąd.

Na wydajność może wpływać sposób wdrożenia wyglądu: dodatkowe arkusze, skrypt zmieniający kolory po załadowaniu albo ciężkie efekty wizualne. Sama paleta nie jest jednak zamiennikiem optymalizacji JS, obrazów i serwera.

Dlaczego jeden dobry wynik nie wystarczy?

Optymalizując sklep na Magento 2 z Hyvä, wykonaliśmy dwa lokalne pomiary Lighthouse dla tej samej strony kategorii. Na mobile uzyskaliśmy 94 i 73 punkty. LCP wyniósł odpowiednio 2,5 i 5,7 s, mimo że w obu przypadkach dotyczył tego samego obrazu pierwszego produktu. Desktop osiągnął 100 punktów.

Wszystkie te przebiegi zgłosiły przekroczenie limitu czasu ładowania, więc wyniki traktowaliśmy jako diagnostyczne i potencjalnie niepełne. Nie były to potwierdzone wyniki PageSpeed Insights ani dane CrUX. Nie jest to również porównanie Hyvä z innym motywem.

W słabszej próbie obraz pobrał się szybko, ale jego wyświetlenie nastąpiło później. To pokazuje, dlaczego trzeba oddzielać czas pobierania od czasu renderowania. Samo dalsze kompresowanie pliku nie wyjaśni takiego problemu. Analiza etapów LCP.

W pracy nad sklepem porównujemy kilka prób, medianę i rozrzut, zachowując te same warunki. Raportów z błędami nie traktujemy jako stabilnego punktu odniesienia. Sprawdzamy także zachowanie po zaakceptowaniu cookies, po otwarciu wyszukiwarki i po dodaniu produktu do koszyka.

Checklista Magento i Hyvä: droga do 95–100 punktów

Poniższa lista pomaga zaplanować audyt i odbiór prac. Nie jest gwarancją czterech wyników 100/100. Ocena zależy od strony, konfiguracji, warunków testu i wersji Lighthouse. Zielony wynik nie zastępuje też ręcznych testów dostępności, audytu bezpieczeństwa ani strategii SEO.

Pomiar i punkt odniesienia

• Zbadano stronę główną, kategorię, produkt, wyszukiwarkę i kluczowe kroki zakupowe.
• Wykonano osobne pomiary mobile i desktop, w kilku porównywalnych próbach.
• Zapisano wersję narzędzia, profil urządzenia, stan zgód i zakres wyników; wyjaśniono timeouty.
• Sprawdzono LCP, INP i CLS z CrUX lub własnego monitoringu, jeśli dostępne.
• Rozróżniono dane pojedynczego URL od danych całej domeny.
• Przetestowano pierwszą wizytę, powrót użytkownika i działanie po interakcji.

Serwer, nginx i Varnish — Performance

• Magento działa w trybie produkcyjnym, z prawidłowo przygotowanymi zasobami statycznymi.
• Publiczne strony osiągają Varnish HIT; sprawdzono też czas odpowiedzi przy MISS.
• Cache poprawnie rozróżnia warianty sklepu, a dane prywatne nie trafiają do wspólnej odpowiedzi.
• Zmiana produktu, ceny lub treści poprawnie unieważnia odpowiedni cache.
• Nginx kompresuje odpowiednie zasoby tekstowe i obsługuje nowoczesny protokół HTTP.
• Pliki wersjonowane mają odpowiednie nagłówki cache; HTML i odpowiedzi prywatne mają osobną politykę.
• PHP-FPM, OPcache i backend cache są skonfigurowane zgodnie z wersją Magento oraz zasobami serwera.
• Cron, indeksowanie, importy i boty nie powodują skoków czasu odpowiedzi.

Moduły, JavaScript i CSS — Performance

• Każdy aktywny moduł ma uzasadnienie biznesowe; usunięto niepotrzebne duplikaty funkcji.
• Integracje Hyvä nie przywracają bez potrzeby ciężkich zależności poprzedniego frontendu.
• JS i CSS modułów trafiają tylko na strony, które używają ich funkcji.
• Skrypty odroczono z zachowaniem zależności, kolejności i zdarzeń inicjalizacji.
• Przetestowano selektywne x-defer i ładowanie komponentów przy użyciu.
• Krytyczne style są dostępne przed pierwszym renderowaniem; nie pojawia się miganie układu.
• GTM, piksele, czat i widgety mają przejrzane wyzwalacze oraz koszt uruchomienia.
• Zmiany analityki zachowują uzgodnione zachowanie zgód i poprawne zdarzenia e-commerce.
• HTML, DOM i JSON-LD nie zawierają zbędnych, powielonych danych.
• Koszyk, filtry, sortowanie, paginacja i checkout działają po optymalizacji.

Zdjęcia i stabilność układu — Performance

• Grafiki mają odpowiednie wymiary, jakość i format; zweryfikowano rzeczywisty transfer.
• Responsywne warianty obrazów odpowiadają rozmiarom wyświetlania.
• Rozpoznano element LCP osobno dla mobile i desktop.
• Obraz LCP nie jest opóźniany przez lazy loading ani zbędną inicjalizację JS.
• Wysoki priorytet nadano tylko uzasadnionym zasobom.
• Obrazy, banery i osadzane treści mają zarezerwowane miejsce w układzie.
• Sprawdzono logo, favicon, grafiki CMS i obrazy dodawane przez moduły.
• Proces publikowania nowych zdjęć obejmuje generowanie zoptymalizowanych wariantów.

Kolory i obsługa interfejsu — Accessibility

• Tekst, ceny, przyciski i komunikaty mają wymagany kontrast na rzeczywistych tłach.
• Sprawdzono kontrast istotnych kontrolek oraz widoczność fokusu klawiatury.
• Błąd, promocja i wybór nie są komunikowane wyłącznie kolorem.
• Linki i przyciski mają zrozumiałe dostępne nazwy; formularze mają etykiety.
• Zdjęcia informacyjne mają adekwatny tekst alternatywny, a dekoracyjne pusty alt.
• Menu, filtry, popupy i koszyk można obsłużyć klawiaturą.
• Sprawdzono powiększenie strony, mały ekran oraz podstawową obsługę czytnikiem ekranu.

Jakość techniczna — Best Practices

• Strona i jej zasoby działają przez HTTPS, bez mixed content.
• Wyjaśniono błędy konsoli, nieudane żądania i ostrzeżenia wskazane przez audyt.
• Biblioteki i moduły są utrzymywane; przejrzano zgłoszone podatności.
• Obrazy zachowują proporcje, a funkcje nie korzystają niepotrzebnie z przestarzałych API.
• Wysoki wynik potwierdzono razem z działającymi płatnościami, formularzami i zgodami.

Widoczność techniczna — SEO

• Strony przeznaczone do indeksowania zwracają właściwy status i nie mają przypadkowego noindex.
• robots.txt nie blokuje potrzebnych stron ani zasobów.
• Tytuł i meta description odpowiadają zawartości strony.
• Canonical jest poprawny; osobno przejrzano wersje językowe i hreflang.
• Linki nawigacyjne są możliwe do odczytania przez roboty, a paginacja działa poprawnie.
• Dane strukturalne zweryfikowano osobnym narzędziem i odpowiadają widocznej treści.
• Przejrzano mapę strony i indeksację w Search Console — również poza zakresem punktacji Lighthouse.

Automatyczne testy dostępności obejmują tylko część możliwych problemów. Nawet wynik 100 wymaga uzupełnienia testem ręcznym. Jak liczona jest dostępność w Lighthouse.

Od czego zacząć prace w swoim sklepie?

Najpierw ustalmy, na co klient czeka. Jeśli na odpowiedź serwera — zaczynamy od backendu i cache. Jeśli na obraz — sprawdzamy jego wykrywanie, pobieranie i wyświetlanie. Jeśli strona jest widoczna, ale reaguje z opóźnieniem — analizujemy pracę JavaScriptu i komponentów.

Następnie wdrażamy jedną logiczną grupę poprawek i ponawiamy pomiary oraz testy zakupowe. Dzięki temu wiadomo, co pomogło i czy koszt zmiany był uzasadniony. Samo osiągnięcie progów Core Web Vitals nie gwarantuje wyniku 95: Performance jest wyliczany z kilku ważonych metryk. Zasady punktacji Lighthouse.

Hyvä pozwala zacząć od lekkiego frontendu. Utrzymanie tej przewagi wymaga świadomych decyzji przy każdym kolejnym module, banerze i narzędziu marketingowym. Warto więc traktować wydajność jako kryterium odbioru kolejnych wdrożeń, a nie jednorazowy projekt zakończony zrzutem ekranu z zielonym wynikiem.

Jeśli planujesz wdrożenie Hyvä albo chcesz przyspieszyć istniejący sklep, skontaktuj się z zespołem kowal.store. Punktem wyjścia powinien być audyt konkretnych stron i ścieżki zakupowej — z listą przyczyn, priorytetów oraz pomiarami przed i po zmianach.