Tester przyjazności mobilnej

Tester przyjazności mobilnej – sprawdź responsywność strony dla Google

Google używa Mobile-First Indexing od 2019 roku – mobilna wersja strony jest główną wersją indeksowaną. Strona nieprzyjazna mobilnie = niższy ranking. Narzędzie sprawdza kluczowe aspekty mobile-friendliness: viewport, wielkość czcionek, touch targets, szybkość i responsywność.

Jak tester sprawdza przyjazność mobilną

Tester nie ocenia wyglądu strony ani jej estetyki. Pobiera HTML pod wskazanym adresem z nagłówkiem User-Agent typowym dla smartfona, a następnie renderuje dokument w wirtualnym oknie o szerokości zbliżonej do typowego telefonu (zwykle 360–414 px). Dopiero na wyrenderowanym układzie wykonywane są pomiary: szerokość i wysokość elementów klikalnych, odstępy między nimi, rozmiar czcionki w blokach tekstowych oraz to, czy jakikolwiek element wystaje poza szerokość viewportu i wymusza przewijanie w poziomie.

Kluczowe jest to, że test patrzy na wynik działania CSS, a nie na sam kod źródłowy. Znacznik meta viewport odczytywany jest z sekcji head i sprawdzany pod kątem obecności parametrów width=device-width oraz initial-scale=1. Natomiast rozmiar przycisku czy czcionki zależy od arkuszy stylów, mediów i fontów, więc dopiero po renderowaniu wiadomo, czy dany element faktycznie spełnia progi. Dlatego strona może mieć poprawny viewport, a mimo to dostać ostrzeżenia — bo np. wysokość przycisku spada do wartości poniżej 48 px dopiero przy węższym ekranie.

Ocena opiera się na progach referencyjnych: touch targets min. 48 × 48 px, odstępy min. 8 px, czcionka min. 14–16 px, brak poziomego przewijania, brak technologii Flash. Osobno sprawdzane są metryki szybkości: LCP poniżej 2,5 s, FID/INP poniżej 100 ms i CLS poniżej 0,1. Tester podaje listę naruszeń zamiast jednego zbiorczego wyniku punktowego, dzięki czemu od razu wiadomo, które poprawki mają największy wpływ na odbiór strony na telefonie. Wynik jest pomiarem laboratoryjnym — powstaje w kontrolowanych warunkach, a nie z realnych sesji użytkowników.

Przykład: karta produktu w sklepie internetowym

1. Uruchamiasz test na adresie karty konkretnego produktu — nie na stronie głównej, bo to właśnie widoki szczegółowe generują najwięcej problemów z układem.
2. Narzędzie pobiera stronę z nagłówkiem smartfona i odczytuje znacznik meta viewport. W tym przypadku zawiera on width=device-width i initial-scale=1, więc ten punkt przechodzi bez zastrzeżeń.
3. Sprawdzany jest rozmiar czcionek. Opis produktu i tabela rozmiarów mają ustawione 12 px, czyli poniżej progu 14 px — pojawia się ostrzeżenie o tekście zbyt małym do czytania bez powiększania.
4. Test mierzy elementy klikalne. Przycisk dodania do koszyka ma wysokość mniejszą niż 48 px, a sąsiedni link do zapytania o produkt stoi bliżej niż 8 px od niego — zgłoszone zostają dwa naruszenia: za mały cel dotyku i za mały odstęp.
5. Narzędzie wykrywa, że tabela rozmiarów ma sztywną szerokość większą niż viewport i wystaje poza ekran, co wymusza przewijanie poziome. To błąd krytyczny, bo rozjeżdża cały układ strony.
6. Na końcu sprawdzana jest szybkość. Gdy zdjęcie główne produktu nie jest skompresowane i nie ma lazy loadingu, największy element widoku ładuje się dłużej niż zalecane 2,5 s dla LCP, a brak zarezerwowanego miejsca na baner powoduje przesuwanie treści i podnosi CLS.
7. Wynik to lista poprawek z priorytetami: najpierw przewijanie poziome i touch targets, potem czcionki, na końcu optymalizacja obrazów i rezerwacja miejsca pod elementy dynamiczne.

Progi, które sprawdza tester, i typowe poprawki

Jak korzystać z wyniku testu

• Testuj realne podstrony, nie tylko stronę główną — karty produktów, formularze, koszyk i widoki artykułów mają inne układy i to w nich najczęściej wychodzą problemy z touch targets oraz przewijaniem poziomym.
• Powtarzaj test po każdej zmianie szablonu — aktualizacja motywu, wtyczki czy skryptu reklamowego potrafi cofnąć wcześniejsze poprawki, zwłaszcza w zakresie CLS i rozmiaru czcionek.
• Łącz wynik z PageSpeed Insights — to narzędzie pokazuje oddzielnie wyniki dla mobile i desktop oraz dane od rzeczywistych użytkowników, czego test układu nie zastąpi.
• Zajrzyj do Search Console — raport użyteczności mobilnej wskazuje adresy, na których Google napotkało problemy, i pomaga ustalić kolejność napraw.
• Sprawdź stronę na wolnym łączu — na mobile LCP jest zwykle gorszy niż na desktopie ze względu na słabszą sieć i mniejszą moc urządzenia; test w warunkach laboratoryjnych nie zawsze to pokaże.

Czego tester nie wychwyci

• Emulacja to nie prawdziwy telefon — renderowanie zależy od silnika przeglądarki, czcionek systemowych i wersji systemu, więc wynik może się różnić od tego, co widzi użytkownik iPhone'a czy taniego Androida.
• Nie ocenia użyteczności treści — narzędzie zmierzy rozmiar tekstu, ale nie powie, czy akapit jest zrozumiały, czy treść nie jest zbyt długa i czy najważniejszy przycisk stoi w widocznym miejscu.
• Nie klika i nie przewija — stany po interakcji, czyli rozwinięte menu, modal, komunikaty formularza czy koszyk, pozostają poza testem, mimo że to tam często pojawiają się elementy zasłaniające treść.
• Nie zastępuje danych pomiarowych z realnych sesji — próg nie jest jednoznaczny z oceną, bo decyduje rozkład wartości w czasie; wynik z laboratorium i dane z raportu CrUX mogą się różnić.

Najczęstsze pytania

Powiązane narzedzia: analiza szybkosci strony, tester responsywnosci i Google PageSpeed Insights.