Google napisał, że witryna jest nieskuteczna na mobile. Winne okazały się liczniki
Search Console pokazał dla naszej witryny 102 nieskuteczne adresy na urządzeniach mobilnych — i te same 102 zielone na komputerze. Pierwsza hipoteza o animacji tła nie przetrwała pomiaru. Winne okazały się tagi reklamowe, a najdroższym drobiazgiem druga kopia tej samej biblioteki ważącej 189 KB. Analiza z liczbami i instrukcja w sześciu krokach.
W Search Console dla naszej własnej witryny zapaliło się: 102 adresy „nieskuteczne" na urządzeniach mobilnych — i dokładnie te same 102 zielone na komputerze. Jedna witryna, jeden układ, dwa werdykty. Zajrzeliśmy głębiej, pierwsza oczywista hipoteza okazała się błędna, a winowajcą było coś, co stoi niemal na każdej witrynie i czego właściciel zwykle w ogóle nie uważa za część serwisu. Poniżej cała analiza z pomiarami i instrukcja, jak sprawdzić i naprawić swoje.
Co właściwie mierzy Google
Metryka nazywa się INP — Interaction to Next Paint. Google opisuje ją tak:
„INP to metryka oceniająca ogólną reaktywność strony na działania użytkownika przez obserwację opóźnienia wszystkich kliknięć, dotknięć i naciśnięć klawiszy w trakcie wizyty".
Progi: dobrze — do 200 ms, wymaga poprawy — od 200 do 500 ms, źle — powyżej 500 ms.
web.dev, dokumentacja INPKluczowe, co warto zrozumieć właścicielowi: INP nie mierzy szybkości ładowania. Mierzy, ile czasu mija od dotknięcia do momentu, w którym ekran widocznie zareagował. Strona może otworzyć się w sekundę i mimo to być „nieskuteczna", jeśli po otwarciu jest zajęta sobą i nie zdąża odpowiedzieć na palec.
I druga ważna rzecz: to metryka polowa. Google zbiera ją od prawdziwych odwiedzających, a nie z testu laboratoryjnego. Dlatego w raporcie aktualizuje się z opóźnieniem i w ruchomym oknie — natychmiastowej zieleni po poprawce nie będzie.
Dlaczego mobilny jest czerwony, a komputer zielony
Odpowiedź jest nudna i w pełni tłumaczy rozbieżność: procesor telefonu jest cztery do ośmiu razy wolniejszy od komputerowego. Ten sam kawałek pracy, który na laptopie zajmuje 60 ms i pozostaje niezauważony, na telefonie rozciąga się do 300–500 ms — i człowiek już widzi, że przycisk „się zaciął". Układ nie ma z tym nic wspólnego: kod jest ten sam, różni się tylko szybkość jego wykonania.
Pierwsza hipoteza okazała się błędna
Na naszej stronie głównej jest animacja tła i podejrzenie padło na nią od razu — tak samo, jak padnie u większości właścicieli: „coś się na stronie rusza, więc to ono spowalnia". Zamiast ją wyłączać i mieć nadzieję, zmierzyliśmy trzy warianty tego samego ekranu: jak jest, z wyłączoną animacją i z zablokowanymi tagami zewnętrznymi.
Mierzyliśmy nie „wrażenie", lecz konkretną wielkość — czas blokowania głównego wątku: sumę tego, o ile długie zadania przekraczają 50 ms. Dopóki takie zadanie trwa, przeglądarka nie może odpowiedzieć na dotknięcie, i właśnie z tego składa się INP.
Wynik zamknął sprawę. Wyłączenie animacji nie dało nic — 1840 ms wobec 1782 ms wyjściowych, różnica w granicach błędu, a formalnie nawet gorzej. Za to zablokowanie tagów zewnętrznych ścięło czas blokowania z 1782 do 378 ms. 79% czasu, w którym strona nie mogła odpowiedzieć na palec, tworzył nie nasz kod i nie animacja.
Prawdziwy winowajca
W <head> stały cztery tagi i wszystkie cztery standardowe, takie, które właściciel wstawia i zapomina: licznik analityki, tag systemu reklamowego i dwa piksele sieci społecznościowej. Wszystkie z atrybutem async, wszystkie „nieblokujące". Łącznie około 600 KB zewnętrznego JavaScriptu.
Dalej znalazło się to, dla czego warto przeczytać ten rozdział. Biblioteka licznika ważąca 189 KB pobierała się i wykonywała dwa razy.
Powód jest banalny. Mamy dwa identyfikatory — analitykę i reklamę. Dla każdego system wydaje gotowy snippet z własną linią podłączenia, a właściciel uczciwie wkleja oba. Ale biblioteka w nich jest jedna i ta sama: obsługuje wszystkie identyfikatory przez osobne wywołania konfiguracji. Druga kopia nie dodaje nic — po prostu jeszcze raz się pobiera, jeszcze raz jest parsowana i jeszcze raz wykonywana na tym samym wolnym procesorze telefonu.
Jeśli macie podłączoną analitykę i konto reklamowe tego samego systemu — z dużym prawdopodobieństwem macie ten sam obraz. Sprawdza się w minutę, sposób poniżej w kroku 3.
Dlaczego „async" nie ratuje
To drugie miejsce, w którym intuicja zawodzi. Atrybut async znaczy: „nie wstrzymuj parsowania HTML, pobieraj równolegle". Uczciwie robi swoje — strona renderuje się, nie czekając na tag.
Ale gdy plik już się pobrał, i tak trzeba go wykonać, a wykonuje się w tym samym jedynym głównym wątku, który odpowiada na dotknięcia. async usuwa blokadę parsowania, ale nie usuwa zajętości wątku — a INP mierzy właśnie ją. Stąd typowa sytuacja: strona pokazała się szybko, wszystkie liczniki są „asynchroniczne", a metryka czerwona.
Jeszcze jedna pułapka: samo odroczenie nic nie daje
Nasuwa się rozwiązanie — odłożyć ładowanie tagów do chwili, gdy przeglądarka się zwolni. Tak zrobiliśmy. I zmierzyliśmy.
Czas blokowania po samym odroczeniu wyniósł 2101 ms wobec 2026 ms wyjściowych — czyli zrobiło się nieco gorzej. Logika jest prosta: odroczenie przesuwa pracę w czasie, ale jej nie usuwa. Praca nigdzie nie znikła, po prostu wykonuje się później — czasem dokładnie wtedy, gdy człowiek już zaczął stukać w ekran.
Zadziałało co innego: usunięcie drugiej kopii biblioteki. Po nim czas blokowania spadł do 1775 ms, a razem z nim podciągnęło się wszystko inne — pierwsze wyrenderowanie z 1128 do 824 ms, odpowiedź serwera z 669 do 335 ms.
Co zrobić z własną witryną: sześć kroków
Poniżej kolejność, w której każdy krok ma sens po poprzednim. Do każdego dołączone jest sprawdzenie, po którym widać, że został wykonany.
Upewnić się, że problem jest wasz
Otwórzcie w Search Console sekcję podstawowych wskaźników internetowych i spójrzcie na zakładkę mobilną osobno od komputerowej. Właśnie osobno: rozbieżność „telefon czerwony, komputer zielony" to najczęstsza postać tego problemu, a patrząc tylko na podsumowanie, łatwo ją przeoczyć.
Jeśli zakładka mobilna jest zielona — dalej można nie czytać, tego problemu nie macie.
Zmierzyć, a nie zgadywać
Główny błąd na tym kroku to zacząć wyłączać to, co wygląda ciężko. My omal nie wyłączyliśmy animacji, która nie miała z tym nic wspólnego. Zmierzcie trzy warianty tej samej strony: jak jest, bez podejrzanego i bez tagów zewnętrznych.
Najbardziej dostępny sposób to DevTools w Chrome: zakładka Performance, spowolnienie procesora czterokrotnie i emulacja urządzenia mobilnego, nagrać 10–15 sekund życia strony i spojrzeć na długie zadania. Są podświetlone, a przy każdym widać, który plik je zrodził.
Sprawdzić, czy jedna biblioteka nie ładuje się dwa razy
To najtańsze zwycięstwo z całej listy. Otwórzcie zakładkę Network w DevTools, odfiltrujcie po js i przejrzyjcie listę: czy nie ma tej samej nazwy pliku dwa razy, z różnymi parametrami w adresie.
Typowy przypadek to licznik analityki i tag reklamowy tego samego systemu: snippety różne, plik jeden. Zostawcie jedno podłączenie, a drugi identyfikator ustawcie osobnym wywołaniem konfiguracji. Nic nie przepadnie: biblioteka obsługuje oba.
<!-- było: dwa snippety, ta sama biblioteka dwa razy -->
<script async src="…/tag.js?id=ID-1"></script>
<script async src="…/tag.js?id=ID-2"></script>
<!-- jest: jedna biblioteka, identyfikatorów ile trzeba -->
<script async src="…/tag.js?id=ID-1"></script>
<script>
config('ID-1');
config('ID-2');
</script>
Odroczyć tagi, nie tracąc ani jednego zdarzenia
Dopiero po kroku 3 — bo samo odroczenie nie pomaga, zmierzyliśmy to. Ale w parze pozwala uwolnić krytyczne pierwsze sekundy.
Sedno chwytu: wynieść pliki zewnętrzne z <head> i doładowywać je przy pierwszym z trzech zdarzeń — bezczynność głównego wątku, timeout 3 sekund albo pierwsze dotknięcie ekranu. Dotknięcie na tej liście jest obowiązkowe: jeśli człowiek już wchodzi w interakcję ze stroną, tag jest potrzebny natychmiast, inaczej stracicie właśnie aktywną sesję.
Zdarzenia przy tym nie giną i to jest kluczowy szczegół. Malutkie funkcje-zaślepki zostają w <head> i odkładają wszystkie wywołania do kolejki; gdy biblioteka wreszcie się załaduje, odtwarza kolejkę w całości. Tak te snippety są zaprojektowane — kolejkę przewidzieli ich autorzy.
Zmierzyć ponownie i nie czekać na natychmiastową zieleń
Po wdrożeniu powtórzcie pomiar z kroku 2 — powinniście zobaczyć spadek czasu blokowania. Natomiast raport w Search Console nie zzielenieje od razu: buduje się na danych prawdziwych odwiedzających w ruchomym oknie i aktualizuje z opóźnieniem liczonym w tygodniach.
To normalne i nie jest powodem, by wycofywać poprawkę albo robić drugą na wierzchu pierwszej. Pomiar laboratoryjny mówi, że jest lepiej — więc pole potwierdzi to później.
Jeśli nie pomogło — rezerwa
Gdy tagi zewnętrzne są uporządkowane, a metryka wciąż nie jest w normie, dalej idą w kolejności malejącego zwrotu: zbędne liczniki dublujące się przeznaczeniem; nieużywany CSS (u nas na stronie głównej 92% reguł nigdy się nie stosuje); cache'owanie HTML, jeśli strona jest wydawana zupełnie bez cache.
Osobno warto uczciwie zapytać, czy potrzebujecie wszystkich podłączonych liczników. Każdy z nich to cudzy kod wykonujący się na telefonie waszego odwiedzającego, podczas gdy ten czeka na reakcję na naciśnięcie.
Czego nie robić
Krótko
„Nieskuteczne na urządzeniach mobilnych przy zielonym komputerze" prawie zawsze znaczy jedno: strona jest zajęta wykonywaniem cudzego kodu na wolnym procesorze telefonu. W naszym przypadku tagi zewnętrzne dawały 79% czasu blokowania, a najdroższym drobiazgiem okazała się druga kopia tej samej biblioteki ważącej 189 KB — ładowała się po prostu dlatego, że snippet kopiuje się po jednym na każde konto.
Jeśli macie zrobić jedną rzecz od razu — otwórzcie zakładkę Network na swojej witrynie i zobaczcie, czy jakiś plik licznika nie pobiera się dwa razy. To sprawdzenie na minutę i jest darmowe.
Skanowanie pokaże ciężkie strony, blokujące skrypty i resztę znalezisk technicznych — z podziałem według wagi.
Częste pytania
Czym jest INP w prostych słowach?
To czas od dotknięcia ekranu do momentu, w którym strona widocznie zareagowała. Google uznaje za dobry wynik do 200 ms, a za zły powyżej 500 ms. Metryka ocenia reaktywność, a nie szybkość ładowania: strona może otworzyć się szybko i mimo to długo nie odpowiadać na naciśnięcia.
Dlaczego witryna jest nieskuteczna na mobile, a skuteczna na komputerze?
Ponieważ procesor telefonu jest cztery do ośmiu razy wolniejszy od komputerowego. Ten sam skrypt, który na komputerze wykonuje się niezauważalnie w 60 ms, na telefonie rozciąga się do 300–500 ms i człowiek widzi opóźnienie. Kod jest przy tym ten sam — różni się tylko szybkość wykonania.
Czy to prawda, że analityka spowalnia witrynę?
W naszym pomiarze tagi zewnętrzne dawały 79% czasu blokowania głównego wątku: 1782 ms z nimi wobec 378 ms bez nich. To nie powód, by usuwać analitykę zupełnie, ale powód, by sprawdzić, ile macie tagów, czy się nie dublują i kiedy dokładnie się ładują.
Czy async pomaga przy skrypcie analityki?
Częściowo. Atrybut async zdejmuje blokadę parsowania HTML, więc strona renderuje się wcześniej. Ale pobrany plik i tak wykonuje się w głównym wątku, a INP mierzy zajętość właśnie tego wątku. Skrypt asynchroniczny może zepsuć metrykę tak samo jak zwykły.
Czy można odroczyć liczniki i nie stracić konwersji?
Tak, jeśli zostawicie w head funkcje-zaślepki, które odkładają wywołania do kolejki do czasu załadowania biblioteki — tak te snippety są zaprojektowane. Koniecznie włączcie pierwsze dotknięcie ekranu do zdarzeń uruchamiających ładowanie, inaczej można stracić aktywną sesję. Po wdrożeniu sprawdźcie, że zdarzenia docierają.
Po jakim czasie raport w Search Console zzielenieje po poprawce?
Nie od razu. Wskaźnik zbiera się od prawdziwych odwiedzających w ruchomym oknie i aktualizuje z opóźnieniem liczonym w tygodniach. Kierujcie się własnym pomiarem laboratoryjnym: jeśli czas blokowania spadł, pole potwierdzi to później.
Źródła
Własny pomiar PromoPilot, 28 sierpnia 2026: emulacja Pixel 5 ze spowolnieniem procesora czterokrotnie, obserwacja długich zadań i opóźnienia reakcji na dotknięcia na żywej witrynie.
web.dev, dokumentacja metryki INP: definicja, progi „dobrze / wymaga poprawy / źle", polowy charakter pomiaru.
Google Search Console, raport „Podstawowe wskaźniki internetowe": osobne zakładki dla urządzeń mobilnych i komputerów.
