Core/Dash Dimension: Typ wejścia (INP)

Wymiar: Typ wejścia INP (inpit)

Wymiar Typ wejścia (INP) rejestruje typ zdarzenia DOM, który wywołał pojedynczą najgorszą interakcję podczas wizyty użytkownika na stronie. Wartością jest surowa nazwa zdarzenia z przeglądarkowego Event Timing API: click, keydown, pointerdown, pointerup, keypress i kilka innych.

INP to metryka najgorszego przypadku. Nie uśrednia interakcji. Znajduje jedną interakcję, która trwała najdłużej od wejścia do następnego malowania (next paint) i raportuje ten czas. Wymiar typu wejścia mówi Ci, co dokładnie robił użytkownik w tamtym momencie. To różnica między wiedzą "INP wynosi 450ms" a wiedzą "INP wynosi 450ms, ponieważ użytkownik wpisywał tekst w Twoje pole wyszukiwania".

Event Timing API grupuje powiązane zdarzenia w jedną logiczną interakcję. Dotknięcie ekranu dotykowego wyzwala pointerdown, pointerup oraz click jako jedną grupę. Pojedynczy, najdłuższy handler zdarzenia w tej grupie determinuje opóźnienie interakcji. CoreDash rejestruje typ zdarzenia z najdłuższym handlerem – tym, który spowolnił interakcję.

Dlaczego Typ Wejścia ma znaczenie dla INP

Każdy typ wejścia mapuje się na inną część Twojej bazy kodu JavaScript. Jeśli widzisz keydown jako dominujący typ wejścia na stronie ze słabym INP, od razu wiesz, że problem leży w handlerach wciśnięć klawiszy: autouzupełnianiu, wyszukiwaniu w trakcie pisania, walidacji formularzy uruchamianej przy każdym naciśnięciu klawisza. Jeśli widzisz click, problem dotyczy handlerów przycisków i linków: logiki nawigacji, aktualizacji stanu, otwierania okien modalnych, synchronicznych wywołań analityki.

Bez tego wymiaru, dochodzenie w sprawie INP rozpoczyna się od profilowania sesji, kroków odtwarzania błędów i zgadywania, jaką interakcję próbował wykonać użytkownik z 75. percentyla. Dzięki wymiarowi typu wejścia, od razu przeskakujesz do odpowiedniego handlera. Oszczędność czasu jest realna.

Typ wejścia ujawnia również różnice między platformami. Witryna z intensywną nawigacją z klawiatury przez zaawansowanych użytkowników pokaże wysoki odsetek zdarzeń keydown prowadzących do słabego INP. Produkt używany głównie na urządzeniach mobilnych zdominuje pointerdown. Ta sama strona, ten sam wynik INP, a poprawka zostanie zastosowana w innych handlerach w zależności od tego, kim tak naprawdę są Twoi użytkownicy.

Typy wejścia

click i pointerdown

Są to najpopularniejsze typy wejścia w danych CoreDash, stanowiące około 75% zdarzeń z najgorszym INP. Na komputerach stacjonarnych click reprezentuje zwolnienie przycisku myszy. Na urządzeniach mobilnych tapnięcie uruchamia pełen łańcuch: pointerdown odpala się jako pierwsze, gdy palec dotyka ekranu, następnie pointerup, gdy się unosi, a na końcu click. CoreDash rejestruje to zdarzenie w łańcuchu, które miało najdłuższy handler.

Handlery kliknięć to główne miejsce ciężkiej, synchronicznej pracy JavaScript. Pojedyncze kliknięcie elementu nawigacji może wyzwolić aktualizacje zarządzania stanem, mutacje DOM, zdarzenia analityczne i ponowne renderowanie – wszystko w tym samym zadaniu. Każda milisekunda synchronicznej pracy w handlerze kliknięcia to milisekunda dodana do INP.

Rozwiązaniem dla wolnych handlerów kliknięć jest dekompozycja zadań. Użyj <code>scheduler.yield()</code>, aby rozbić handler na mniejsze zadania i pozwolić przeglądarce renderować pomiędzy nimi. Przenieś niekrytyczną pracę, taką jak wywołania analityki, do setTimeout z zerowym opóźnieniem lub odrocz je całkowicie do requestIdleCallback. Przeglądarka musi ukończyć tylko tę pracę, która wpływa na odpowiedź wizualną przed następnym malowaniem. Cała reszta może poczekać.

keydown

Wejście z klawiatury stanowi około 15% zdarzeń z najgorszym INP w danych CoreDash, ale generuje jedne z najbardziej rażących wyników. Powodem jest częstotliwość: użytkownik piszący w polu wyszukiwania wyzwala keydown przy każdym wciśnięciu klawisza. Jeśli Twój handler zajmuje 200ms, użytkownik doświadcza 200ms opóźnienia po każdym wpisanym znaku. 10-znakowe zapytanie wyszukiwania zamienia się w 2 sekundy skumulowanego czasu blokowania.

Głównymi winowajcami są implementacje wyszukiwania podczas pisania, które wykonują synchroniczne żądania API lub uruchamiają kosztowny diffing DOM przy każdym naciśnięciu klawisza, a także walidacja formularzy, która sprawdza ponownie cały formularz po każdym naciśnięciu klawisza. Te wzorce działają dobrze w małej skali, ale załamują się w warunkach rzeczywistych użytkowników.

Standardowymi rozwiązaniami są debouncing i odciążanie. Zastosuj debounce w swoim handlerze wyszukiwania, aby uruchamiał się tylko wtedy, gdy użytkownik wstrzyma pisanie, zazwyczaj od 200 do 300 milisekund. W przypadku bardziej złożonego przetwarzania, jak np. fuzzy search w dużym lokalnym zbiorze danych, przenieś obliczenia do Web Worker, aby główny wątek (main thread) pozostał wolny i mógł renderować następną klatkę po każdym zdarzeniu keydown.

pointerup

Zdarzenia zwalniania wskaźnika (pointer up) stanowią około 8% najgorszych przypadków INP w danych CoreDash. pointerup uruchamia się na końcu sekwencji dotknięcia lub kliknięcia, po pointerdown. Niektóre frameworki i biblioteki UI bindują swoje główne zachowanie "kliknięcia" do pointerup, a nie do click, co przenosi handler na wcześniejszy etap w cyklu życia interakcji.

Gdy pointerup pojawia się jako dominujący typ wejścia, proces dochodzenia jest taki sam jak w przypadku handlerów kliknięć: znajdź jaki JavaScript jest uruchamiany w handlerze i oddziel pracę, która musi blokować następne malowanie, od pracy, którą można odroczyć. Różnica w stosunku do click jest zwykle decyzją na poziomie frameworka, a nie poziomu aplikacji, więc poprawka może wymagać dostosowania sposobu, w jaki biblioteka komponentów obsługuje bindowanie interakcji.

Workflow debugowania

1. Filtruj po typie wejścia w CoreDash: Otwórz zestawienie INP dla problematycznego adresu URL i sprawdź, jaki typ wejścia dominuje w najgorszych interakcjach. Jeśli jeden typ odpowiada za ponad połowę Twoich złych zdarzeń INP, zacznij od tego. Dystrybucja mówi Ci, gdzie powinieneś poświęcić swój czas na profilowanie.
2. Odtwórz za pomocą odpowiedniej interakcji: Otwórz Chrome DevTools, włącz profilowanie Performance i wykonaj dokładnie ten typ interakcji, który został wskazany w CoreDash. Strona zdominowana przez keydown powinna być testowana poprzez pisanie. Strona zdominowana przez click powinna być testowana kliknięciami myszy na elementach, z którymi wchodzą w interakcje Twoi użytkownicy. Zarejestruj trace i zidentyfikuj długie zadania w głównym wątku, które uruchamiają się zaraz po zdarzeniu wejściowym.
3. Zastosuj poprawkę specyficzną dla typu i zweryfikuj: Dla problemów z keydown, dodaj debouncing i sprofiluj ponownie. Dla problemów z click, dodaj wywołania scheduler.yield() w logicznych punktach przerwania wewnątrz handlera. Wdróż do środowiska testowego, użyj WebPageTest ze skryptowaniem interakcji lub panelu Performance w Chrome DevTools i upewnij się, że czas trwania zadania spadł, zanim wypuścisz to na produkcję.

Praktyczna zasada inżynierska

• keydown dominuje Twoje złe INP: Dodaj debouncing do wszystkich handlerów wyszukiwania i autouzupełniania. 200ms opóźnienia to standardowy punkt startowy. Jeśli obliczenia są kosztowne nawet przy takim opóźnieniu, przenieś je z głównego wątku do Web Worker.
• click lub pointerdown dominuje: Twoje handlery wykonują zbyt dużo synchronicznej pracy, zanim przeglądarka zdąży namalować klatkę. Zrób audyt każdego handlera kliknięcia na problematycznym URL. Usuń synchroniczne wywołania analityki. Podziel wieloetapową logikę używając scheduler.yield() pomiędzy krokami.
• pointerup dominuje: Sprawdź, czy Twój framework binduje logikę interakcji do pointerup zamiast click. Poprawka jest zwykle taka sama jak dla handlerów kliknięć, ale punkt wejścia w bazie kodu jest inny.
• Mieszana dystrybucja bez wyraźnego faworyta: Problemem nie jest jeden typ interakcji. Sprofiuj trzy najwolniejsze pojedyncze interakcje ze wszystkich typów i zajmij się nimi w kolejności ich wpływu. Nie optymalizuj w oderwaniu od rzeczywistości.

Typ wejścia to sygnał kierunkowy. Nie mówi Ci, co jest powolne. Mówi Ci, gdzie szukać. Gdy już wiesz, czy Twoi użytkownicy klikają, piszą, czy dotykają ekranu, kiedy INP ulega pogorszeniu, każdy kolejny krok dochodzenia staje się szybszy i bardziej ukierunkowany.