Audyt strony mobilnej: lista kontroli UX, szybkości i konwersji

Dobry audyt obejmuje reprezentatywne typy stron i zadania użytkowników, a nie przypadkowe przeglądanie witryny. Wybierz stronę główną, stronę usługi lub kategorii, podstronę szczegółową oraz formularz albo koszyk. W sklepie dodaj kartę produktu, wyszukiwanie, filtrowanie i checkout; w serwisie firmowym sprawdź cennik, kontakt i lokalizację.

Zdefiniuj zadanie przed rozpoczęciem testu: na przykład znalezienie usługi i wysłanie zapytania albo zakup konkretnego produktu. Zapisz wspólne dane dla całego audytu: datę, URL, urządzenie, system, przeglądarkę, szerokość widoku i stan zgód cookies. Przy kolejnych usterkach wystarczy odwołać się do tego zapisu, zamiast powtarzać go w każdej notatce.

Chrome DevTools pozwala wstępnie sprawdzić różne widoki. Otwórz stronę w Chrome, wybierz F12, a następnie ikonę Device Mode i ustaw Dimensions na Responsive albo wybierz urządzenie. W panelu Network można symulować ograniczenie sieci, a w Performance przeanalizować ładowanie. Emulacja nie odwzorowuje w pełni procesora, systemowej klawiatury ani wszystkich zachowań przeglądarki, dlatego ważne ścieżki potwierdź na telefonie.

Jeżeli problemy obejmują także treści, SEO lub architekturę informacji, uzupełnij kontrolę o audyt strony internetowej.

Responsywny układ powinien zapewniać dostęp do treści i funkcji bez niezamierzonego przewijania w poziomie. Sprawdź kilka typowych szerokości oraz punkty tuż przed i po zmianie układu. Przykładowe widoki to 320, 360, 390, 430 i 768 pikseli CSS; breakpointy dobieraj do projektu, a nie do nazw konkretnych modeli telefonów.

Na każdej szerokości obejrzyj nagłówek, menu, główny przycisk, karty, tabele, galerie, banery i stopkę. Przejdź przez całą stronę, bo błąd może ujawnić się dopiero przy długim tytule, cenie z większą liczbą cyfr albo komunikacie walidacji. Sprawdź też, czy pasek cookies lub pływający przycisk kontaktu nie zasłania treści.

Szeroką tabelę umieść w jej własnym obszarze przewijania i zasygnalizuj możliwość przesunięcia zawartości. Nie ukrywaj problemu globalnym `overflow-x: hidden`, bo może odciąć przyciski lub informacje. Obrazy i komponenty powinny dopasować się do kontenera zamiast wymuszać większą szerokość.

Gdy audyt obejmuje szersze problemy techniczne i doświadczenie użytkownika, audyt cyfrowy strony pomaga uporządkować dalsze kontrole.

Interakcje sprawdzaj dotykiem, nie tylko kursorem. Otwórz menu, przejdź do podstrony, wróć, rozwiń akordeon i użyj wyszukiwarki. Po otwarciu menu sprawdź, czy tło nie przewija się razem z panelem i czy można go zamknąć dostępnym przyciskiem lub gestem. Jeżeli serwis obsługuje klawisz Escape, zweryfikuj także tę metodę.

Przejdź formularz pole po polu. Sprawdź etykiety, rodzaj klawiatury, autouzupełnianie oraz zachowanie po błędnym wpisie. Pole e-mail powinno ułatwiać wpisanie adresu, a pole telefonu nie powinno narzucać nieopisanego formatu. Komunikat walidacji ma wskazać pole i wyjaśnić, jak poprawić dane. Po wysłaniu potwierdź, że użytkownik widzi rezultat.

W sklepie przetestuj wybór wariantu, filtry, sortowanie, zmianę liczby sztuk i usuwanie produktu z koszyka. Przy otwartej klawiaturze ekranowej sprawdź widoczność przycisku kontynuacji. Zgoda cookies i wyskakujące okna nie mogą zasłaniać przycisku wysyłania ani wyboru wariantu.

Dostępność formularzy i obsługi interfejsu warto ocenić równolegle z audytem WCAG, zwłaszcza gdy etykiety lub przyciski trudno rozpoznać.

Oddziel wynik laboratoryjny od danych terenowych, bo opisują różne warunki. PageSpeed Insights używa Lighthouse do symulowanego testu, a dane rzeczywistych użytkowników pobiera z Chrome User Experience Report (CrUX), jeżeli dostępna jest wystarczająca próbka. Raport Core Web Vitals w Search Console pokazuje dane terenowe dla grup podobnych adresów, a nie pełny wynik każdego URL-a. Dokumentacja PageSpeed Insights wyjaśnia, że gdy brakuje danych dla strony, PSI może pokazać dane zastępcze na poziomie originu, czyli dla wszystkich stron w danym originie.

Dobre progi Core Web Vitals ocenia się na 75. percentylu: LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1. Dane terenowe opisują doświadczenia użytkowników z okresu objętego raportem, natomiast Lighthouse wykonuje pojedynczą symulację. Różnice wynikają między innymi z urządzeń, sieci, pamięci podręcznej i zachowań odwiedzających.

Jeżeli PSI nie pokazuje danych terenowych dla URL-a, sprawdź, czy udostępnia dane zastępcze dla całego originu. Nie przypisuj ich automatycznie do konkretnej podstrony ani szablonu: inne strony w originie mogły mieć odmienne doświadczenia. W raporcie zachowaj osobno wynik Lighthouse, zakres danych terenowych i informację, czy dane dotyczą URL-a, czy originu. Zielony wynik laboratoryjny sam w sobie nie potwierdza, że formularz działa ani że strona szybko ładuje się u każdego użytkownika.

Treść mobilna ma pozwolić podjąć decyzję bez powiększania widoku. Sprawdź rozmiar tekstu, kontrast, długość wierszy i hierarchię nagłówków. Oceń czytelność przy domyślnych ustawieniach przeglądarki, a następnie przy większym rozmiarze tekstu dostępnym w urządzeniu.

Obejrzyj zdjęcia produktów, grafiki usług, ikony i banery. Ważny obiekt nie powinien wypadać poza kadr po przycięciu, a tekst na grafice nie może być jedynym nośnikiem informacji. Sprawdź, czy użytkownik może szybko znaleźć podstawowy komunikat, cenę, dostępność i przycisk działania.

Czytaj sekcje w kolejności wizualnej. Długie akapity podziel na logiczne fragmenty, zachowując warunki, koszty i ograniczenia istotne dla decyzji. Ikona powinna być zrozumiała z kontekstu i mieć dostępną nazwę dla technologii asystujących. Odnośniki wyróżnij także wyglądem lub kontekstem, nie samym kolorem.

Przejdź na telefonie całą ścieżkę od pierwszego wejścia do zakończenia zadania, bez skrótów administracyjnych. W sklepie wybierz produkt i wariant, wskaż dostawę oraz płatność, a następnie sprawdź potwierdzenie zamówienia. Na stronie usługowej znajdź ofertę, odczytaj warunki i wyślij formularz albo wykonaj połączenie.

Zapisz liczbę kroków, błędy, niejasne koszty, nieoczekiwane przeładowania oraz miejsca, w których użytkownik musi wracać do poprzedniego widoku. W formularzu sprawdź błąd sieci i ponowne wysłanie. W sklepie koszt dostawy i warunki płatności powinny być widoczne przed końcowym potwierdzeniem, a zmiana koszyka nie powinna bez potrzeby kasować wcześniej wpisanych danych.

Perspektywa KC Mobile: zrzut ekranu często nie pokazuje problemu, który występuje dopiero po dotknięciu przycisku, wpisaniu danych lub zamknięciu banera. Dlatego zapisujemy zarówno widok, jak i działanie prowadzące do błędu. Dzięki temu zespół może odtworzyć usterkę i sprawdzić poprawkę w tym samym scenariuszu.

Problemy z użytecznością sklepu można zestawić z analizą SWOT sklepu internetowego. Jeśli lokalna widoczność strony jest częścią zadania, sprawdź też audyt lokalnej strony internetowej.

Priorytet ustal na podstawie wpływu na zadanie użytkownika, częstości występowania i kosztu poprawki. Problem, który uniemożliwia zakup lub wysłanie formularza, wyprzedza drobną różnicę w odstępie. Jeśli usterka występuje we wspólnym nagłówku lub komponencie, sprawdź jej wpływ na kilka podstron.

Prowadź rejestr z identyfikatorem usterki, krokami odtworzenia, dowodem, wpływem, częstością, kosztem, właścicielem i statusem. Dane urządzenia, widoku i adresu przechowuj we wspólnym zapisie audytu. Po wdrożeniu oznacz problem jako zweryfikowany dopiero po powtórzeniu scenariusza. Naprawy związane z widocznością organiczną można uzupełnić o audyt SEO krok po kroku.

Jeśli potrzebujesz zewnętrznej diagnozy, audyt cyfrowy strony może połączyć kontrolę mobilną z technicznym przeglądem serwisu. Dla sklepu zakres prac opisuje audyt sklepu internetowego.

PageSpeed Insights łączy dane laboratoryjne Lighthouse z danymi terenowymi CrUX, jeśli są dostępne. Wpisz pełny URL, wybierz raport Mobile i zanotuj, czy część danych terenowych dotyczy adresu strony, czy całego originu. Lighthouse służy do diagnozy w symulowanych warunkach; sam wynik nie zastępuje sprawdzenia interfejsu i ścieżek na telefonie.

Chrome DevTools pomaga odtworzyć układ i diagnozować błędy w przeglądarce. Włącz Device Mode, ustaw wymiary, zajrzyj do Console w poszukiwaniu błędów JavaScript, a w Network filtruj żądania Img, CSS i JS. Przy błędzie 404 lub zasobie zablokowanym zachowaj adres żądania i jego status. Telefon nadal jest potrzebny do sprawdzenia klawiatury ekranowej, gestów i różnic między systemami.

W Google Search Console otwórz raport Core Web Vitals i wybierz Mobile. Raport prezentuje dane terenowe dla grup podobnych adresów, które mają dane w CrUX; przykładowy URL reprezentuje grupę, a nie każdy adres z osobna. Jeśli diagnozujesz pobieranie lub renderowanie przez Google, użyj Inspekcji adresu URL i testu opublikowanego adresu.

Automatyczny pomiar nie przejdzie za użytkownika przez cały koszyk ani nie oceni, czy koszt dostawy jest zrozumiały. Używaj narzędzi do pytań, na które odpowiadają: PSI mierzy wydajność, DevTools ułatwia diagnozę w przeglądarce, a Search Console pokazuje problemy w danych terenowych Google.