Wydajność mobilna PrestaShop: dlaczego telefon wypada gorzej

Wydajność mobilna PrestaShop rozstrzyga o wyniku sklepu bardziej niż wydajność na komputerze, bo w większości sklepów detalicznych to telefon odpowiada za większość sesji. Jednocześnie jest to warstwa mierzona najrzadziej, bo zespół pracuje na szybkim łączu, na dużym ekranie i na wersji sklepu, którą przeglądarka trzyma już w pamięci podręcznej.

Efekt: sklep, który „u nas działa dobrze”, potrafi mieć na telefonie wyraźnie gorsze wskaźniki i niższą konwersję, a nikt nie łączy tych dwóch faktów.

Dlaczego telefon wypada gorzej

Nie z jednego powodu, tylko z czterech naraz, i każdy działa niezależnie od pozostałych.

• Wolniejsze i mniej stabilne połączenie. Sieć komórkowa ma większe opóźnienia niż łącze stacjonarne, a jakość zmienia się w trakcie sesji.
• Słabszy procesor. Przetworzenie tej samej ilości kodu zajmuje telefonowi wielokrotnie więcej czasu niż komputerowi. To dotyka wskaźnika INP mocniej niż czegokolwiek innego.
• Mniejszy ekran przy tej samej treści. Strona zaprojektowana na desktop i zwężona do telefonu wymaga pobrania wszystkiego, a wyświetla ułamek naraz.
• Inna wersja z cache. Warstwa buforująca trzyma osobne wersje dla urządzeń mobilnych i desktopowych. Sprawdzenie jednej nie mówi nic o drugiej.

Ostatni punkt jest źródłem najczęstszego nieporozumienia przy weryfikacji zmian. Dodanie parametru omijającego cache do adresu pokazuje wersję wygenerowaną na świeżo, więc „działa z parametrem” nie znaczy „działa dla klienta”. Wersję mobilną trzeba sprawdzić osobno i bez obchodzenia cache.

Wydajność mobilna PrestaShop: jak ją zmierzyć uczciwie

Progi Core Web Vitals są te same dla obu typów urządzeń: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Różni się to, jak łatwo je spełnić.

Rozdziel dane, nie uśredniaj

Zbieraj wskaźniki osobno dla urządzeń mobilnych i desktopowych, i osobno dla czterech szablonów: strony głównej, listingu kategorii, karty produktu i checkoutu. Uśredniony wynik ukrywa problem występujący tylko na jednym urządzeniu, a to właśnie ten problem zwykle kosztuje najwięcej.

Test terenowy, który zastępuje pół audytu

Wejdź na własny sklep z telefonu, przez sieć komórkową, poza domem i poza biurem, na urządzeniu, na którym sklep nie jest w pamięci podręcznej. Przejdź od strony głównej przez wyszukiwarkę do karty produktu, dodaj coś do koszyka i wejdź w checkout.

Zobaczysz rzeczy, których nie pokaże żaden raport, bo nie generują zdarzeń: baner doładowujący się sekundę po reszcie i przesuwający treść w dół, zdjęcie pojawiające się dopiero po przewinięciu, przycisk reagujący z opóźnieniem, pole formularza wywołujące klawiaturę alfanumeryczną tam, gdzie trzeba wpisać kod pocztowy.

Symulacja słabszego urządzenia

Narzędzia deweloperskie przeglądarki pozwalają spowolnić procesor i ograniczyć przepustowość. To nie zastępuje testu terenowego, ale pozwala powtarzalnie sprawdzić zmiany bez wychodzenia z biura. Ustaw spowolnienie procesora i wolne połączenie, potem powtórz ten sam pomiar po każdej zmianie.

Co na telefonie poprawia najwięcej

Kolejność jest inna niż na komputerze, bo inne są wąskie gardła.

Dwie pierwsze pozycje pokrywają się z pracą, którą i tak wykonujesz przy optymalizacji obrazów PrestaShop i przy optymalizacji skryptów PrestaShop. Różnica polega na tym, że na telefonie ich efekt jest wyraźniejszy, więc jeśli musisz wybrać, od czego zacząć, zacznij od pomiaru mobilnego.

Jeden motyw responsywny czy osobna wersja mobilna

Pytanie wraca przy każdej przebudowie i ma dziś dość jednoznaczną odpowiedź, ale warto rozumieć, skąd się bierze.

Motyw responsywny to jeden zestaw szablonów dopasowujący układ do szerokości ekranu. Zaleta: jedna wersja do utrzymania, jeden adres, brak ryzyka rozjazdu treści. Wada: telefon pobiera cały kod, także ten obsługujący układy, których nigdy nie zobaczy, i cały arkusz stylów, w którym większość reguł dotyczy szerszych ekranów.

Osobna wersja mobilna pozwala wysłać dokładnie to, co potrzebne, ale mnoży pracę przy każdej zmianie i tworzy ryzyko, że obie wersje rozejdą się funkcjonalnie. W praktyce sklepy, które poszły tą drogą, wracają do jednego motywu po pierwszym roku utrzymania.

Rozsądny kompromis to jeden motyw z warunkowym ładowaniem: wspólne szablony, ale zasoby dobierane do kontekstu. Karuzela ze strony głównej nie musi ładować swojej biblioteki na telefonie, jeśli w wersji mobilnej pokazujesz pojedynczą grafikę. Skrypt obsługujący rozbudowane menu desktopowe nie jest potrzebny przy menu wysuwanym.

Zasada praktyczna przy projektowaniu: zacznij od wersji mobilnej i dokładaj elementy dla szerszych ekranów, zamiast projektować na desktop i ukrywać części na telefonie. Ukryte elementy nadal są pobierane i przetwarzane, więc ukrywanie nie jest optymalizacją.

Gdzie wydajność spotyka się z interfejsem

Część problemów mobilnych nie jest problemami wydajności w sensie technicznym, ale klient odbiera je identycznie: jako sklep, który nie działa. Warto je adresować przy tej samej okazji, bo wymagają dotknięcia tych samych szablonów.

• Typ klawiatury. Pole numeru telefonu i kodu pocztowego powinno wywoływać klawiaturę numeryczną, pole adresu e-mail klawiaturę z symbolem małpy. To jeden atrybut w kodzie pola.
• Automatyczne uzupełnianie. Poprawnie opisane pola pozwalają przeglądarce wypełnić adres jednym dotknięciem. Bez tego klient przepisuje wszystko ręcznie, na małej klawiaturze.
• Rozmiar obszaru dotyku. Wybór metody dostawy i płatności musi dać się kliknąć kciukiem bez powiększania strony.
• Widoczność przycisku. Przycisk przejścia dalej schowany pod klawiaturą zatrzymuje klienta na etapie, który właśnie skończył wypełniać.
• Menu i filtry. Nawigacja fasetowa zaprojektowana na desktop bywa na telefonie listą, przez którą trzeba przewijać ekran za ekranem.

Ostatni punkt łączy się wprost z wydajnością listingu PrestaShop: na telefonie liczy się nie tylko czas generowania listy, ale też liczba dotknięć, które dzielą klienta od zawężenia wyników do sensownej liczby produktów.

Cache a wersja mobilna

Warstwa buforująca rozpoznaje typ urządzenia i trzyma osobne wersje strony. Ma to trzy konsekwencje praktyczne, o których łatwo zapomnieć.

Podwójna liczba wpisów. Każda strona istnieje w cache w dwóch wariantach, więc rozgrzewanie cache po wdrożeniu trwa dłużej, a pierwsze wejście na wersję mobilną po zmianie jest wolne niezależnie od tego, jak dobrze działa desktop.

Weryfikacja wymaga dwóch przebiegów. Po każdej zmianie sprawdź obie wersje. Poprawka widoczna na komputerze może nie dotrzeć do wersji mobilnej, dopóki jej wpis w cache nie wygaśnie.

Błędne przypisanie wariantu. Rzadkie, ale kosztowne: jeśli warstwa cache źle rozpozna urządzenie, klient na telefonie dostanie wersję desktopową. Objawia się to skargami na „rozjechany sklep” u części użytkowników, których nie da się odtworzyć w biurze.

Warunki sieciowe, o których łatwo zapomnieć

Klient mobilny nie jest po prostu klientem na wolniejszym łączu. Jego połączenie zmienia się w trakcie sesji, bywa przerywane i ma większe opóźnienia niezależnie od deklarowanej przepustowości. To ma trzy konsekwencje praktyczne.

Liczba połączeń kosztuje więcej niż waga. Przy dużych opóźnieniach każdy dodatkowy host, z którym trzeba się połączyć, to zauważalny koszt jeszcze przed pobraniem pierwszego bajtu. Dlatego serwowanie czcionek i skryptów z własnego serwera zamiast z usług zewnętrznych daje na telefonie więcej niż na komputerze.

Przerwana sesja to porzucony koszyk. Klient w tramwaju traci zasięg w tunelu. Jeśli sklep nie zachowa zawartości koszyka i danych wpisanych w formularzu, zamówienie przepada, a przyczyna nie ma nic wspólnego ze sklepem. Zachowywanie stanu formularza jest tu tanią polisą.

Powrót po nieudanej płatności. Na telefonie przejście do aplikacji banku i powrót do przeglądarki jest ścieżką standardową, a nie wyjątkiem. Sklep musi przyjąć klienta z powrotem z zachowanym koszykiem i możliwością wyboru innej metody. Utrata koszyka w tym momencie to utrata zamówienia, które było o krok od realizacji.

Ostatni punkt należy formalnie do checkoutu, ale wymieniamy go tutaj, bo objawia się prawie wyłącznie na urządzeniach mobilnych i w raportach ginie wśród ogólnych porzuceń koszyka.

Kolejność prac

1. Pomiar rozdzielony na urządzenia i szablony. Bez tego nie wiadomo, czy problem jest mobilny, czy ogólny.
2. Test terenowy z telefonu. Kwadrans, wyłapuje rzeczy niewidoczne w danych.
3. Zdjęcia. Największa dźwignia LCP przy wolnym łączu.
4. Skrypty i czas ich wykonania. Największa dźwignia INP przy słabszym procesorze.
5. Stabilność układu. Wymiary obrazów i rezerwacja miejsca dla elementów doładowywanych.
6. Interfejs checkoutu. Klawiatury, obszary dotyku, widoczność przycisków.

Punkty od trzeciego do piątego to ta sama praca, którą wykonujesz dla całego sklepu, tyle że priorytetyzowana pod telefon. Punkt szósty jest wyłącznie mobilny i nie ma odpowiednika na komputerze.

Typowe błędy w pracy nad wersją mobilną

Cztery rzeczy, które wracają w sklepach i każda kosztuje więcej, niż się wydaje.

Testowanie na własnym telefonie w biurze. Najnowsze urządzenie, szybkie wi-fi i sklep w pamięci podręcznej to warunki, w jakich nie działa żaden klient. Test ma sens na sieci komórkowej, poza biurem i na urządzeniu, które nie odwiedzało sklepu wcześniej.

Ukrywanie elementów zamiast ich usuwania. Sekcja schowana regułą stylu na małych ekranach jest nadal pobierana i przetwarzana. Klient płaci za nią transferem i czasem procesora, nie widząc jej. Jeśli element nie jest potrzebny na telefonie, nie powinien być wysyłany.

Poprawianie wskaźnika zamiast doświadczenia. Odroczenie wszystkiego, co się da, poprawia wynik w pojedynczym teście i pogarsza odbiór sklepu, bo treść pojawia się kawałkami. Mierz na realnym ruchu i patrz na to, co widzi klient.

Weryfikacja z pominięciem cache. Sprawdzenie strony z parametrem omijającym warstwę buforującą pokazuje wersję generowaną na świeżo. To użyteczne przy diagnozie, ale nie mówi nic o tym, co dostaje klient. Wersję mobilną sprawdzaj także bez takiego parametru.

Checkout na telefonie zasługuje na osobny pomiar

Checkout jest szablonem, na którym wydajność przekłada się na pieniądze najbardziej bezpośrednio, bo klient dotarł już do końca ścieżki i kosztował pełną cenę pozyskania. Jest też szablonem, którego nie da się buforować, więc pokazuje surowy czas wykonania aplikacji.

Trzy rzeczy, które warto zmierzyć osobno dla tego szablonu na urządzeniach mobilnych:

• Czas przejścia między krokami. Jeśli każdy krok wymaga przeładowania i trwa zauważalnie długo, klient przy trzecim kroku zaczyna wątpić, czy zamówienie doszło.
• Reakcja na wybór metody dostawy. Przeliczenie kosztów po zaznaczeniu opcji bywa najwolniejszą operacją w całym sklepie, bo odpytuje reguły przewoźników.
• Powrót z bramki płatniczej. Na telefonie przejście do aplikacji banku i powrót jest ścieżką standardową. Zmierz, ile trwa i czy koszyk zostaje zachowany.

Wybór punktu odbioru wymagający otwarcia zewnętrznej mapy zasługuje na osobną uwagę, bo na telefonie oznacza wyjście z checkoutu i powrót. Sprawdź, czy powrót zachowuje całą zawartość formularza. Utrata wpisanych danych w tym miejscu to utrata zamówienia, które było o krok od realizacji.

Warto też sprawdzić zachowanie klawiatury ekranowej. Gdy wysuwa się nad polem formularza, przesuwa cały układ i potrafi zasłonić przycisk przejścia dalej. Klient widzi wtedy wypełnione pole i nie widzi, co ma zrobić dalej, więc przewija w górę i w dół, szukając kolejnego kroku. To jest problem, którego nie zobaczysz na komputerze i którego nie pokaże żaden wskaźnik.

Co mierzyć po zmianach

Trzy liczby, zbierane osobno dla urządzeń mobilnych, wystarczą do prowadzenia tego obszaru: LCP na karcie produktu, INP na listingu z filtrami oraz udział sesji mobilnych zakończonych zamówieniem wobec sesji desktopowych. Trzecia liczba jest tą, która przekonuje zarząd, bo mówi o pieniądzach, a nie o milisekundach.

Różnica w konwersji między urządzeniami nigdy nie zejdzie do zera i nie taki jest cel. Chodzi o to, żeby zmniejszała się po pracy nad wydajnością, a jeśli się nie zmniejsza, przyczyna leży w interfejsie albo w checkoucie, nie w prędkości. Miejsce tego obszaru wśród pozostałych porządkuje przewodnik o optymalizacji PrestaShop, a usługowo zamyka go optymalizacja wydajności PrestaShop.

Progi i sposób ich liczenia opisuje dokumentacja Google na web.dev. Warto do niej zajrzeć przed rozmową z wykonawcą, bo pozwala odróżnić pomiar z realnego ruchu od wyniku pojedynczego testu.