Użyj tej listy kontrolnej wydajności sklepu mobilnego, aby priorytetyzować Core Web Vitals, optymalizować obrazy, wybrać SSR vs CSR i ustawić cache przy ograniczonym budżecie.
Szybki sklep mobilny to nie idealne wyniki w labie. To to, jak działa na prawdziwym telefonie ze słabym sygnałem i jednym kciukiem. Coś użytecznego pojawia się szybko, strona nie skacze w trakcie ładowania obrazów, a każde dotknięcie daje wyraźną odpowiedź.
Prędkość ma znaczenie, bo klienci decydują błyskawicznie. Jeśli pierwszy widok jest wolny lub chaotyczny, użytkownicy odchodzą. Gdy strona sprawia wrażenie opóźnionej, spada zaufanie. A jeśli koszyk lub płatność zwalnia, spada współczynnik konwersji. Na mobilu nawet małe opóźnienie wydaje się większe, bo ekran jest mały, a rozproszenia są o jedno przesunięcie dalej.
Przy ograniczonym budżecie celem nie jest pełna przebudowa. Myśl „najpierw duże zyski”: napraw rzeczy, które najbardziej poprawiają doświadczenie, i odpuść zmiany zajmujące tygodnie, a oszczędzające milisekundy. Większość sklepów uzyskuje większość korzyści dzięki garści praktycznych poprawek.
Miej na uwadze te cele:
Częsty błąd: obraz hero ładuje się późno, przycisk „Dodaj do koszyka” przesuwa się w dół i użytkownicy stukają w niewłaściwe miejsce lub rezygnują. Ustawienie wymiarów obrazów i wcześniejsze ładowanie głównego obrazu często poprawia doświadczenie bardziej niż zmiana frameworka.
Jeśli budujesz z Koder.ai, te same priorytety obowiązują: wypuść najmniejszy, najszybszy pierwszy widok, a potem dodawaj funkcje bez przeciążania strony.
Prace nad wydajnością przy ograniczonym budżecie idą sprawniej, gdy zakres jest mały i mierzalny. Zacznij od 1–2 stron, które najbardziej wpływają na przychody i zaufanie, a potem mierz je tak samo za każdym razem.
Wybierz strony, na których mobilni użytkownicy albo zostają, albo odchodzą. Dla wielu sklepów to strona produktu plus strona główna (pierwsze wrażenie) albo strona kategorii (przeglądanie). Jeśli checkout jest największym miejscem odpływu, uwzględnij go, ale utrzymaj początkowy zakres wąski.
Następnie wypisz działania, które użytkownicy faktycznie wykonują na tych stronach. Myśl w kategoriach stuknięć, nie funkcji: wyszukiwanie, zastosowanie filtra, otwarcie produktu, zmiana wariantu, dodanie do koszyka. To pomoże wychwycić problemy, które testy laboratoryjne pomijają, jak wolne aktualizacje filtrów czy opóźniona informacja o dodaniu do koszyka.
Używaj konsekwentnie dwóch prawdziwych urządzeń: jednego średniej klasy Androida (tam problemy pokażą się szybko) i jednego przeciętnego iPhone'a. Testuj z tego samego miejsca Wi‑Fi lub tego samego hotspota, by wyniki były porównywalne.
Dla każdej strony docelowej zanotuj prostą bazę:
Jeśli LCP na stronie produktu wynosi 5.2s na średnim Androidzie i elementem LCP jest główny obraz produktu, już wiesz, gdzie najpewniej są prace o wysokim ROI.
Core Web Vitals to trzy sygnały, które mocno odwzorowują, jak strona działa na telefonie:
Praktyczna kolejność: napraw duże problemy z LCP, potem zajmij się INP, na końcu dopracuj CLS. Strona, która pokazuje główną treść po 5 sekundach, nadal będzie sprawiać wrażenie wolnej nawet jeśli dotknięcia są szybkie. Gdy LCP będzie w porządku, opóźnienia wejścia i przesunięcia układu staną się bardziej widoczne.
Typowe problemy mapujące się na każde z KPI:
Przydatne cele dla użytkowników mobilnych:
Ustalaj cele według typu strony, nie tylko globalnie. Strony produktu i checkout powinny mieć surowsze wymagania, bo tam użytkownik decyduje i kupuje. Strony główne mogą mieć nieco luźniejsze LCP, ale utrzymuj CLS ścisły, by strona wydawała się stabilna.
Jeśli masz naprawić tylko jedną rzecz przy ograniczonym budżecie — popraw obrazy. Na mobilu to one dominują wagę do pobrania, opóźniają LCP i powodują przesunięcia układu, gdy brak jest wymiarów.
Lista kontrolna obrazów, która obejmuje większość sklepów:
srcset z realistyczną wartością sizes.Jedno zabezpieczenie, które zapobiega wielu problemom: zawsze ustawiaj width i height (lub CSS aspect-ratio) dla każdego obrazu. To łatwy sposób na wygranie z CLS.
Typowy wynik: siatka kategorii o wadze 2 MB często spadnie poniżej 400 KB po przejściu na WebP dla miniatur, serwowaniu maksymalnie 640px na mobilu i lekkim obniżeniu jakości. Większość klientów tego nie zauważy, ale czas ładowania tak.
Pierwszy ekran powinien być tani do narysowania. Na mobilu każdy dodatkowy font, reguła CSS i skrypt konkuruje o ten sam ograniczony budżet CPU i sieci.
Customowe fonty to częste „ciche” opóźnienie. Jeśli marka pozwala, zacznij od fontów systemowych i dodaj jeden font customowy później.
Trzymaj to prosto: jedna rodzina, jedna lub dwie wagi (np. 400 i 600) i tylko potrzebne zestawy znaków. Preloaduj tylko pojedynczy plik fontu używany nad foldem i upewnij się, że tekst renderuje się natychmiast (bez pustego nagłówka, dopóki font się ładuje).
CSS rośnie szybko, zwłaszcza z bibliotekami UI i powtarzającymi się komponentami. Trzymaj CSS nad foldem mały, potem ładuj resztę po tym, jak pierwszy widok będzie widoczny. Regularnie usuwaj nieużywane style.
Dla skryptów zasada jest prosta: nic nieistotnego nie powinno uruchamiać się zanim użytkownik zobaczy i zacznie czytać. Ciężkie pakiety analityczne, widgety czatu, narzędzia A/B i slidery mogą poczekać.
Szybkie zalecenia dla stron głównej i produktowej:
Jeśli Twój storefront jest w React (w tym kod eksportowany z Koder.ai), rozważ podział galerii produktów i recenzji na osobne chunki. Załaduj tytuł, cenę i główny obraz najpierw, a resztę hydratyzuj po tym, jak strona stanie się używalna.
Przy ograniczonym budżecie celem jest, by strony wejściowe wydawały się natychmiastowe, nawet na telefonie słabszej klasy. Strategia renderowania wpływa na prawie każdą inną optymalizację.
Przydatna zasada:
Praktyczna hybryda sprawdza się dobrze: SSR renderuje shell strony i krytyczną zawartość (tytuł, cenę, główny obraz, przycisk kupna, pierwsze recenzje), a cięższe widgety hydratyzujesz później.
Uważaj na pułapki, które często szkodzą wydajności mobilnej:
Przykład: SSRuj siatkę kategorii z 12 przedmiotami i cenami, ale ładuj filtry (rozmiar, kolor) po pierwszym paint. Klienci mogą przewijać od razu, a UI filtrów przyjdzie chwilę później bez przesuwania układu.
Cache oszczędza pieniądze i sekundy, ale może też uwięzić klientów przy starych cenach, zepsutym JS lub brakującymi obrazami. Cache'uj to, co rzadko się zmienia, na długo, i upewnij się, że wszystko co aktualizujesz można szybko zastąpić.
Zacznij od zasobów statycznych: obrazy, CSS i paczki JS. Daj im długi czas cache, żeby powtórne wizyty były szybkie, szczególnie na mobilnych danych.
Długi cache działa tylko, jeśli nazwy plików zmieniają się razem z zawartością. Używaj wersjonowania plików (hashy w nazwach), żeby nowe buildy trafiały jako nowe pliki.
Cache'uj często czytane rzeczy, które nie zmieniają się per użytkownik (shell strony głównej, strony kategorii, listy produktów, sugestie wyszukiwania). Unikaj cache'owania czegokolwiek, co musi być świeże per użytkownik (koszyk, checkout, konto).
Praktyczna lista kontrolna:
Jeśli wdrażasz przez Koder.ai na AWS, powiąż cache z wersjami release: wersjonuj zasoby, trzymaj świeżość HTML krótką i zapewnij przewidywalny rollback przez kojarzenie cache z wersją release.
INP dotyczy tego, co dzieje się po dotknięciu. Na mobilu opóźnienia są bardzo widoczne. Przycisk „martwy” przez 200–500ms może kosztować sprzedaż, nawet jeśli strona załadowała się szybko.
Testuj na prawdziwym słabszym telefonie, jeśli możesz, nie tylko na laptopie. Przetestuj cztery zadania: otwórz stronę produktu, zmień wariant, dodaj do koszyka, potem otwórz koszyk. Jeśli jakiekolwiek dotknięcie wydaje się wolne lub strona zastyga podczas przewijania, to jest twoje pole do pracy nad INP.
Poprawki, które zwykle poprawiają wynik bez dużych przebudów:
Jeśli wywołanie do koszyka trwa 1–2 sekundy na wolnym połączeniu, nie blokuj strony. Pokaż stan wciśnięcia, dodaj produkt optymistycznie i przerywaj przepływ tylko gdy żądanie zakończy się niepowodzeniem.
Zrób szybki przegląd jednej popularnej strony (często home lub topowy produkt). Użyj prawdziwego telefonu jeśli możesz, albo Chrome DevTools z profilem średniego Androida.
Wybierz jedną stronę i zidentyfikuj element LCP. Załaduj stronę raz i zauważ, co staje się LCP (obraz hero, obraz produktu lub duży nagłówek). Zapisz czas LCP.
Popraw rozmiary obrazów i preloaduj zasób LCP. Upewnij się, że obraz LCP ma poprawne width/height (lub aspect-ratio), serwuj mniejszą wersję na mobil, używaj nowoczesnych formatów i preloaduj tylko ten pojedynczy obraz.
Odkładaj skrypty niekrytyczne dla pierwszego widoku. Opóźnij chaty, heatmapy, A/B testy i ciężkie pakiety recenzji do momentu po używalności strony.
Zatrzymaj przesunięcia układu. Zarezerwuj miejsce dla banerów, karuzel, pasków cookie i gwiazdek recenzji. Unikaj wstawiania treści nad foldem po załadowaniu.
Przetestuj ponownie w tych samych warunkach. Porównaj LCP i CLS. Jeśli LCP się nie ruszyło, sprawdź czas odpowiedzi serwera lub render‑blokujące CSS.
Jeśli budujesz z użyciem narzędzia chatowego jak Koder.ai, uczynij z tego powtarzalną rutynę: zrób snapshot przed i po, by móc szybko cofnąć zmiany, które spowalniają stronę.
Większość problemów to samosabotaż: jeszcze jedna wtyczka, jeszcze jeden slider, jeszcze jeden tag. Przydatna zasada: pokaż prawdziwą treść szybko, potem wzbogacaj.
Błędy pojawiające się najczęściej:
Typowy wzorzec: strona produktu ładuje ogromną bibliotekę karuzeli plus wiele trackerów, a przycisk „Dodaj do koszyka” staje się klikalny późno. Klientom nie zależy na efektach, jeśli dotknięcie wydaje się opóźnione.
Szybkie poprawki, które zwykle pomagają bez przebudowy:
Jeśli używasz Koder.ai, traktuj wydajność jak funkcję: podglądaj zmiany na średnim telefonie i używaj snapshotów, by szybko cofnąć nowy widget, który spowalnia stronę.
Krótka kontrola przed wydaniem jest lepsza niż wielki projekt optymalizacyjny. Traktuj ją jak bramkę: jeśli strona wydaje się wolna na tanim telefonie, napraw to przed wypuszczeniem.
Testuj kluczowe strony (home, kategoria, produkt, start checkout) na prawdziwym średnim Androidzie lub profilu throttlingu:
Jeśli coś wygląda nie tak, napraw największy widoczny problem pierwszy. Jeden za duży obraz lub jeden wczesny skrypt może zepsuć wydanie.
Wybory dotyczące cache i renderowania powinny sprawić, że strony wejściowe będą szybkie bez serwowania przestarzałych cen lub psucia koszyka:
Jeśli budujesz z Koder.ai, prosta „migawka wydajności” przed wydaniami ułatwia porównania, rollback i ponowne testy.
Mały sklep ma około 200 produktów. Większość klientów przychodzi na mobile z reklam społecznościowych, trafia na stronę kategorii, potem na produkt. Zespół ma ograniczony czas deweloperski, więc plan jest prosty: przyspiesz pierwsze dwie strony i stabilizuj interakcje.
Śledzą kilka kluczowych stron (topowa kategoria, topowy produkt, koszyk) i skupiają się na LCP (szybkość głównej treści), CLS (stabilność układu) i INP (responsywność stuknięć).
Zaczynają od największych zwycięstw na stronach kategorii i produktu: obrazy w odpowiednich rozmiarach (bez 2000px na ekranie 360px), nowoczesne formaty (WebP/AVIF), agresywna kompresja dla gridów i jawne wymiary, aby zatrzymać przesunięcia układu. Preloadują pojedynczy obraz hero na stronie produktu i lazy‑loadują resztę.
Wynik: mniej przeskoków podczas przewijania i strony wydają się szybsze jeszcze przed głębszymi pracami.
Następnie redukują pracę na głównym wątku:
Wynik: lepsze INP. Stuknięcia rejestrują się szybciej, a filtrowanie przestaje zamrażać przewijanie.
Dodają SSR dla stron wejściowych (home, top kategoria, produkt), by treść pojawiała się szybciej na wolnych połączeniach. CSR pozostaje dla stron konta i historii zamówień.
Aby zdecydować, które zmiany zostają:
Jeśli budujesz na Koder.ai, snapshoty i wsparcie rollbacku umożliwiają bezpieczniejsze eksperymenty przy zmianach renderowania, skryptów czy struktury strony.
Lista kontrolna pomoże tylko wtedy, gdy stanie się nawykiem. Trzymaj to proste: mierz, zmień jedną rzecz, mierz ponownie. Jeśli zmiana spowalnia stronę, szybko ją wycofaj i idź dalej.
Wybierz 1–2 strony, które dają pieniądze (zwykle home, kategoria, produkt, start checkout) i zastosuj małą rutynę:
To zapobiega losowym optymalizacjom i skupia na tym, co użytkownicy naprawdę zauważają.
Budżety zapobiegają powolnemu narastaniu problemów. Utrzymaj je na tyle małe, by można je egzekwować w reviewach:
Budżety to nie perfekcja. To granice, które chronią doświadczenie mobilne.
Traktuj wydajność jak funkcję: potrzebujesz planu szybkiego rollbacku. Jeśli platforma wspiera snapshoty i rollback, używaj ich przed wydaniami, żeby przywrócić wolną zmianę w kilka minut.
Jeśli chcesz szybko iterować nad renderowaniem i kompromisami wydajności, Koder.ai (koder.ai) może być przydatny do prototypowania i wdrażania zmian z możliwością eksportu źródeł gdy będziesz gotowy. Najważniejszy jest nawyk: małe zmiany, częste kontrole i szybkie cofnięcia, gdy wydajność spada.
Szybki storefront to taki, który działa sprawnie i stabilnie na prawdziwym telefonie: główna treść pojawia się wcześnie, układ się nie przemieszcza, a dotknięcia dają natychmiastową informację zwrotną.
Priorytetem jest perceived speed — pokaż szybko obraz produktu/nazwę/cenę i jasną ścieżkę zakupu, resztę ładuj później.
Zacznij od 1–2 „stron przynoszących pieniądze”, gdzie mobilni użytkownicy decydują, czy zostać. Zazwyczaj są to:
Dodaj checkout tylko jeśli to tam leży największy odpływ; utrzymuj początkowy zakres mały, żeby móc mierzyć zmiany jasno.
Zrób podstawowe pomiary dla każdej wybranej strony:
Konsystencja testów jest ważniejsza niż idealne narzędzia—testuj w ten sam sposób za każdym razem.
Napraw w tej kolejności:
Jeżeli główna treść pojawia się późno, reszta i tak będzie wydawać się wolna, nawet jeśli interakcje są szybkie.
Najwyższy ROI osiągniesz tą listą:
Utrzymaj lekkie pierwsze wyświetlenie:
Celem jest, by telefon pierwsze sekundy przeznaczył na rysowanie treści, a nie na zbędne dodatki.
Dobre domyślne podejście:
Uważaj na opóźnienia hydracji—zbyt dużo JS na starcie może zepsuć INP i sprawić, że dotknięcia będą ignorowane.
Cache'uj mądrze:
Dzięki temu powtórne wizyty będą szybkie, a użytkownicy nie utkną na starych cenach czy brakujących plikach.
Popraw „uczucie” dotknięcia:
Jeśli wywołanie sieciowe trwa 1–2s, nie blokuj interfejsu — daj natychmiastową odpowiedź, a tylko w razie błędu przerwij przepływ.
Proste kroki przed wydaniem:
Jeśli używasz Koder.ai, snapshoty i rollback ułatwiają szybkie cofnięcie zmian, które spowalniają stronę.
width/height lub aspect-ratio, aby zapobiec CLSJeden poprawnie dopasowany i preloadowany główny obraz często daje więcej niż tygodnie przebudowy.