Wymiar Core/Dash: Input Type (INP)

Wymiar: Input Type INP (inpit)

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

INP to metryka typu worst-case. Nie wyciąga średniej z interakcji. Znajduje tę jedną interakcję, która trwała najdłużej od rejestracji wejścia do kolejnego wyrenderowania obrazu, i raportuje ten czas. Wymiar Input Type mówi Ci, co użytkownik robił w tym dokładnie momencie. To różnica między świadomością, że „INP wynosi 450 ms”, a wiedzą, że „INP wynosi 450 ms, ponieważ użytkownik pisał w polu wyszukiwania”.

Event Timing API grupuje powiązane zdarzenia w jedną logiczną interakcję. Stuknięcie w ekran dotykowy uruchamia pointerdown, pointerup i click jako jedną grupę. Pojedynczy, najdłuższy handler zdarzenia w tej grupie decyduje o opóźnieniu interakcji. CoreDash rejestruje typ zdarzenia najdłuższego handlera – czyli tego, który spowolnił interakcję.

Dlaczego Input Type ma znaczenie dla INP

Każdy typ interakcji mapuje się na inną część Twojej bazy kodu JavaScript. Jeśli widzisz, że dominującym typem interakcji na stronie ze słabym INP jest keydown, od razu wiesz, że problem leży w handlerach obsługujących naciśnięcia klawiszy: autouzupełnianiu, wyszukiwaniu w trakcie pisania (search-as-you-type) czy walidacji formularza uruchamianej przy każdym naciśnięciu klawisza. Jeśli widzisz click, problem tkwi w handlerach przycisków i linków: logice nawigacji, aktualizacjach stanu, otwieraniu okien modalnych czy wywołaniach analityki uruchamianych synchronicznie.

Bez tego wymiaru analiza INP zaczyna się od sesji profilowania, prób reprodukcji i zgadywania, jakiej interakcji próbował użytkownik z 75. percentyla. Dzięki wymiarowi Input Type przechodzisz od razu do odpowiedniego handlera. Oszczędność czasu jest realna.

Input type ujawnia również różnice między platformami. Witryna z intensywną nawigacją klawiaturową u zaawansowanych użytkowników pokaże wysoki odsetek zdarzeń keydown pogarszających INP. Produkt używany głównie na urządzeniach mobilnych pokaże dominację zdarzeń pointerdown. Ta sama strona, ten sam wynik INP, a poprawka dotyczy zupełnie innych handlerów w zależności od tego, kim naprawdę są Twoi użytkownicy.

Typy interakcji

click i pointerdown

To najczęstsze typy interakcji w danych CoreDash, odpowiadające za około 75% zdarzeń z najgorszym INP. Na komputerach click oznacza zwolnienie przycisku myszy. Na urządzeniach mobilnych stuknięcie uruchamia cały łańcuch: najpierw pointerdown przy dotknięciu ekranu palcem, potem pointerup przy jego podniesieniu, a na końcu click. CoreDash rejestruje to zdarzenie z łańcucha, którego handler trwał najdłużej.

Handlery click to główne miejsce wykonywania ciężkiej, synchronicznej pracy w JavaScript. Pojedyncze kliknięcie elementu nawigacji może wywołać aktualizacje zarządzania stanem, modyfikacje DOM, zdarzenia analityczne i ponowne renderowanie – wszystko w ramach tego samego zadania. Każda milisekunda synchronicznej pracy w handlerze click to dodatkowa milisekunda dodana do INP.

Rozwiązaniem dla wolnych handlerów click jest dekompozycja zadań. Użyj <code>scheduler.yield()</code>, aby rozbić handler na mniejsze zadania i pozwolić przeglądarce na renderowanie pomiędzy nimi. Przenieś niekrytyczne operacje, takie jak wywołania analityczne, do setTimeout z zerowym opóźnieniem lub odłóż je całkowicie za pomocą requestIdleCallback. Przeglądarka musi przed kolejnym wyrenderowaniem obrazu (next paint) ukończyć tylko te zadania, które wpływają na reakcję wizualną. Cała reszta może poczekać.

keydown

Wprowadzanie danych z klawiatury odpowiada za 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 wywołuje keydown przy każdym naciśnięciu klawisza. Jeśli Twój handler potrzebuje 200 ms, użytkownik doświadcza 200 ms opóźnienia po każdym wpisanym znaku. 10-znakowe zapytanie oznacza 2 sekundy skumulowanego czasu blokowania.

Najczęstszymi winowajcami są mechanizmy wyszukiwania w trakcie pisania (search-as-you-type) wysyłające synchroniczne żądania API lub wykonujące kosztowne porównywanie DOM (diffing) przy każdym naciśnięciu klawisza, a także walidacja formularzy sprawdzająca cały formularz po każdym znaku. Takie wzorce działają dobrze przy małej skali, ale zawodzą w rzeczywistych warunkach użytkowania.

Standardowym rozwiązaniem jest debouncing i odciążanie głównego wątku. Zastosuj debouncing w handlerze wyszukiwania, aby uruchamiał się dopiero po przerwie w pisaniu, zazwyczaj po 200 do 300 milisekundach. W przypadku bardziej złożonych obliczeń, takich jak wyszukiwanie rozmyte (fuzzy search) w dużym lokalnym zbiorze danych, przenieś obliczenia do Web Workera, aby main thread pozostał wolny i mógł wyrenderować kolejną klatkę po każdym zdarzeniu keydown.

pointerup

Zdarzenia pointer up reprezentują około 8% najgorszych przypadków INP w danych CoreDash. pointerup odpala się na końcu sekwencji dotknięcia lub kliknięcia, po pointerdown. Niektóre frameworki i biblioteki UI wiążą swoje główne zachowanie „kliknięcia” ze zdarzeniem pointerup zamiast click, co przenosi wykonanie handlera na wcześniejszy etap cyklu życia interakcji.

Gdy pointerup okazuje się dominującym typem interakcji, proces analizy jest taki sam jak dla handlerów click: znajdź kod JavaScript uruchamiany w handlerze i oddziel zadania, które muszą blokować next paint, od tych, które można odłożyć. Różnica w stosunku do click wynika zazwyczaj z decyzji na poziomie frameworka, a nie samej aplikacji, więc naprawa może wymagać dostosowania sposobu, w jaki biblioteka komponentów obsługuje powiązania interakcji.

Proces debugowania

1. Filtruj według typu interakcji w CoreDash: Otwórz zestawienie INP dla problematycznego adresu URL i sprawdź, który typ interakcji dominuje w najgorszych interakcjach. Jeśli jeden typ odpowiada za ponad połowę słabych zdarzeń INP, zacznij od niego. Ten rozkład wskaże Ci, na co poświęcić czas profilowania.
2. Zreprodukuj problem za pomocą odpowiedniej interakcji: Otwórz Chrome DevTools, włącz profilowanie wydajności (Performance) i wykonaj dokładnie ten typ interakcji, który wskazuje CoreDash. Stronę zdominowaną przez keydown testuj pisząc na klawiaturze. Stronę zdominowaną przez click testuj klikając myszą elementy, z którymi wchodzą w interakcję użytkownicy. Zarejestruj trace i zidentyfikuj long tasks w main thread, które uruchamiają się bezpośrednio po zdarzeniu wejściowym.
3. Zastosuj poprawkę dla konkretnego typu interakcji i zweryfikuj działanie: W przypadku problemów z keydown dodaj debouncing i ponownie przeprowadź profilowanie. Dla problemów z click dodaj wywołania scheduler.yield() w logicznych punktach podziału handlera. Uruchom kod na środowisku testowym, użyj WebPageTest ze skryptami interakcji lub panelu Performance w Chrome DevTools i upewnij się, że czas trwania zadań spadł przed wdrożeniem produkcyjnym.

Praktyczne zasady inżynieryjne

• keydown dominuje w Twoim słabym INP: Dodaj debouncing do wszystkich handlerów wyszukiwania i autouzupełniania. Standardowym punktem wyjścia jest opóźnienie 200 ms. Jeśli obliczenia są kosztowne nawet przy takim opóźnieniu, przenieś je poza main thread za pomocą Web Workera.
• click lub pointerdown dominuje: Twoje handlery wykonują zbyt dużo pracy synchronicznej, zanim przeglądarka zdąży wyrenderować obraz. Przeprowadź audyt każdego handlera click na problematycznym adresie URL. Usuń synchroniczne wywołania analityki. Podziel wieloetapową logikę za pomocą scheduler.yield() między kolejnymi krokami.
• pointerup dominuje: Sprawdź, czy Twój framework nie wiąże logiki interakcji ze zdarzeniem pointerup zamiast click. Sposób naprawy jest zazwyczaj taki sam jak w przypadku handlerów click, ale punkt wejścia w bazie kodu jest inny.
• Rozkład mieszany bez wyraźnego lidera: Problem nie leży w jednym typie interakcji. Sprofiluj trzy najwolniejsze pojedyncze interakcje bez względu na ich typ i zajmij się nimi w kolejności ich wpływu na wynik. Nie optymalizuj w teorii.

Input Type to sygnał nawigacyjny. Nie mówi Ci, co działa wolno, ale wskazuje, gdzie szukać. Gdy dowiesz się, czy Twoi użytkownicy klikają, piszą, czy stukają w ekran w momencie spadku INP, każdy kolejny krok analizy staje się szybszy i bardziej precyzyjny.