Dlaczego audyt strony mobilnej nie działa? Jak znaleźć przyczynę i ją sprawdzić

Najpierw nazwij objaw: brak raportu, brak danych terenowych, niski wynik albo usterka widoku wymagają różnych testów. Brak raportu kieruje diagnozę na adres i dostępność strony, niski wynik na metryki wydajności, a problem z menu lub formularzem na test funkcjonalny.

Zapisz tylko informacje potrzebne do odtworzenia błędu: pełny URL, datę pomiaru, narzędzie, urządzenie lub tryb testu, przeglądarkę i dokładny komunikat. Przy usterce interakcji dopisz sekwencję działań, na przykład: otwarcie menu, odrzucenie cookies, przejście do formularza. Zrzut ekranu albo nagranie krótkiej ścieżki stanowi dowód, który można porównać po poprawce.

Tabela rozdziela problem z uruchomieniem pomiaru od braku danych użytkowników i od usterki interfejsu. PageSpeed Insights dostarcza danych laboratoryjnych Lighthouse i danych terenowych Chrome UX Report, ale nie zastępuje ręcznej kontroli funkcji strony. Google wycofał raport Mobile Usability i narzędzie Mobile-Friendly Test w 2023 roku, dlatego do sprawdzenia dostępu oraz renderowania używaj Inspekcji adresu URL w Search Console, a do zachowania interfejsu telefonu i Chrome DevTools.

Jeśli PSI nie tworzy raportu, zacznij od dokładnego adresu, przekierowań i odpowiedzi serwera, a robots.txt zostaw do osobnej kontroli crawlowania Google. Wpisz do testu pełny URL, który ma być publicznie dostępny, i otwórz go w oknie prywatnym. Sprawdź, czy strona nie przekierowuje do logowania, strony błędu, innej domeny lub wyzwania antybotowego.

Tabela wskazuje, gdzie szukać przyczyny, gdy test nie może pobrać strony. Jeśli odpowiedź serwera jest prawidłowa, ale wynik wyszukiwania lub renderowanie budzi wątpliwości, w Search Console otwórz Inspekcję adresu URL i wybierz test opublikowanego adresu URL. Sprawdź pola dotyczące crawlowania i pobrania strony oraz obejrzyj wyrenderowaną stronę i zablokowane zasoby.

Google Search Console testuje dostęp robota inspekcyjnego i nie diagnozuje samego interfejsu PageSpeed Insights. Robots.txt ma znaczenie, gdy sprawdzasz, czy Google może pobrać stronę lub zasób; sprawdź go pod adresem `https://domena/robots.txt` i potwierdź wynik w Inspekcji adresu URL. Jeśli podejrzewasz WAF, administrator powinien porównać log z godziną testu, adresem URL i identyfikatorem żądania. Gdy potrzebujesz uporządkowanej diagnozy dostępności, wydajności i błędów technicznych, audyt cyfrowy strony pozwala połączyć te obszary w jeden plan działań.

Porównaj dokładnie ten sam wariant adresu i stan strony, z których korzysta użytkownik. `https://domena.pl`, `https://www.domena.pl`, adres z końcowym ukośnikiem i URL z parametrami mogą prowadzić do różnych odpowiedzi lub przekierowań. Wpisz do testu adres docelowy po przekierowaniu, jeśli właśnie ten widok chcesz ocenić.

Odtwórz ścieżkę w czystej sesji: otwórz stronę, zaakceptuj albo odrzuć cookies i wykonaj działanie, które poprzedza usterkę. Dla funkcji wymagającej konta zrób osobny test po zalogowaniu. W ten sposób odróżnisz problem widoczny dla każdego odwiedzającego od problemu zależnego od sesji, zgody lub danych w formularzu.

W Chrome wybierz F12, a następnie ikonę Toggle device toolbar. Tryb Responsive pozwala zmienić szerokość viewportu i sprawdzić breakpointy, czyli szerokości, przy których układ przechodzi do innego wariantu. Emulacja nie odtwarza w pełni dotyku, klawiatury ekranowej ani różnic sprzętowych, więc zgłoszony problem potwierdź na fizycznym telefonie. Jeśli usterka występuje tylko w określonym stanie, przekaż wykonawcy sekwencję działań, która ją wywołuje.

Wyniki PageSpeed Insights mogą się różnić, ponieważ dane Lighthouse i dane CrUX opisują inne warunki pomiaru. Lighthouse wykonuje laboratoryjną symulację ładowania strony, a Chrome UX Report (CrUX) zbiera zagregowane doświadczenia użytkowników Chrome z poprzednich 28 dni. Dane terenowe mogą nie pojawić się dla URL-a z niewystarczającą próbą; wówczas PSI może pokazać dane dla całego pochodzenia witryny albo nie pokazać danych terenowych.

Tabela pomaga dobrać pomiar do pytania: Lighthouse służy do diagnozowania wydajności, CrUX do oceny doświadczeń terenowych, a telefon do sprawdzania konkretnej interakcji. Wyniki laboratoryjne mogą się zmieniać przez warunki sieci, obciążenie urządzenia testowego i serwera. Porównuj powtarzane pomiary wykonane w zbliżonych warunkach oraz konkretne metryki, a nie samą ocenę punktową.

PSI opisuje dane CrUX dla poprzednich 28 dni, a wynik Lighthouse dotyczy pojedynczego testu. Ocena Core Web Vitals wykorzystuje dane terenowe, gdy dostępna jest wystarczająca próba. Dobra ocena laboratoryjna nie dowodzi, że każda rzeczywista sesja jest szybka.

Perspektywa KC Mobile: kiedy dobry raport nie zgadza się ze zgłoszeniem użytkownika, odtwarzamy jego ścieżkę zamiast powtarzać ten sam test strony głównej. Problem może występować po otwarciu menu, zmianie zgody cookies albo przejściu do formularza, więc sam pomiar wydajności go nie wykaże.

Testuj zadania użytkownika na telefonie, a nie sam wygląd zrzutu ekranu. Na stronie wejściowej sprawdź nawigację, na stronie treści czytelność, a na stronie konwersji kontakt, formularz albo zakup. Wybierz podstrony reprezentujące różne szablony witryny.

Sprawdź, czy treść mieści się w szerokości ekranu bez poziomego przewijania i czy baner cookies nie zasłania ważnych przycisków. Otwórz i zamknij menu dotykiem, a następnie przejdź formularz z klawiaturą ekranową. Wyślij niekompletne dane i sprawdź, czy komunikat walidacji wskazuje pole wymagające poprawy.

Opis błędu powinien zawierać działanie, oczekiwany wynik i wynik rzeczywisty, na przykład: "Po odrzuceniu cookies menu zasłania przycisk kontaktu przy szerokości 360 px". To daje osobie wdrażającej punkt do odtworzenia. Jeśli problem dotyczy także obsługi przez technologie asystujące, audyt dostępności WCAG obejmuje kontrolę interfejsu pod kątem dostępności.

Błąd interfejsu może wynikać ze skryptu, który przerwał działanie komponentu, lub zasobu, który nie został pobrany. W Chrome DevTools otwórz kartę Console, przeładuj stronę i sprawdź błędy JavaScript, CORS oraz brakujące pliki. W karcie Network włącz Preserve log, ponów wadliwą czynność i sprawdź żądania zakończone błędem.

Dla fontu sprawdź żądanie WOFF lub WOFF2, kod odpowiedzi i reguły CORS. Dla obrazu sprawdź jego URL i status HTTP; dla CSS potwierdź pobranie arkusza oraz reguły aktywne przy danej szerokości. Jeśli błąd pojawia się dopiero po kliknięciu, włącz zachowywanie logu przed ponowieniem tej interakcji.

Porównaj wadliwą i działającą podstronę, aby zawęzić obszar poszukiwań. Jeśli obie używają tego samego nagłówka, ale tylko jedna psuje się po otwarciu menu, sprawdź skrypt menu, jego zależności i kolejność ładowania. Sam komunikat w Console nie dowodzi związku z usterką; powiąż go z działaniem, po którym interfejs przestaje działać.

Powtarzalny audyt opisuje warunki testu i zapisuje dowód, dzięki któremu druga osoba może odtworzyć ten sam problem. Wybierz co najmniej trzy typy podstron: stronę wejściową, typową treść i stronę konwersji. Dla każdej sprawdź widok oraz najważniejszą interakcję.

Tabela porządkuje informacje potrzebne do powtórzenia testu i przekazania zadania osobie odpowiedzialnej. Priorytet ustaw według wpływu: błąd blokujący zakup lub kontakt ma wyższy priorytet niż przesunięcie elementu dekoracyjnego. Po poprawce wykonaj ten sam test na tym samym adresie, urządzeniu, szerokości i ścieżce.

Dla szerzej zakrojonego przeglądu dostępności, wydajności oraz działania witryny możesz zamówić audyt cyfrowy z planem napraw.

Popraw stronę, gdy powtarzalny błąd utrudnia wykonanie zadania, dostęp do treści albo kontakt z firmą. Niedziałający przycisk, formularz bez wysyłki i menu zasłaniające nawigację są usterkami funkcjonalnymi. Zmienny wynik Lighthouse bez potwierdzonego błędu użytkowego wymaga najpierw porównywalnego pomiaru i analizy metryk.

Priorytet zależy od skutku i zasięgu problemu. Awaria płatności ma większy wpływ niż drobne przesunięcie ozdobnika, a usterka wspólnego nagłówka może dotyczyć wielu podstron. Zapisz, które szablony obejmuje błąd i czy użytkownik ma obejście.

Po wdrożeniu powtórz test w tych samych warunkach i zachowaj dowód przed oraz po zmianie. Wydajność laboratoryjną oceniaj oddzielnie od terenowych danych CrUX, ponieważ te ostatnie obejmują poprzednie 28 dni.

• Audyt strony mobilnej: lista kontroli UX, szybkości i konwersji
• Jak przeprowadzić audyt lokalnej strony internetowej? Cztery obszary do sprawdzenia
• Czy audyt SEO po redesignie strony jest potrzebny? Lista kontroli
• Czym jest analiza SWOT sklepu internetowego i jak przełożyć ją na plan działania