Wymiar Core/Dash: Load State (INP)

Wymiar: Load State INP (inpls)

Wymiar Load State (INP) rejestruje stan gotowości dokumentu w dokładnym momencie przechwycenia interakcji użytkownika. Każde zdarzenie INP w Chrome User Experience Report zawiera tag stanu ładowania: loading, dom-interactive, dom-content-loaded lub complete. CoreDash udostępnia ten tag jako wymiar z możliwością filtrowania i grupowania, dzięki czemu możesz odpowiedzieć na pytanie, na które nie odpowiedzą surowe wyniki INP: kiedy w cyklu życia strony doszło do najgorszej interakcji?

To pytanie wyznacza granicę między dwoma całkowicie różnymi rozwiązaniami technicznymi. Problem z INP skupiający się w stanie loading wymaga strategii odraczania JavaScript. Problem z INP skupiający się w stanie complete wymaga odchudzenia funkcji obsługi zdarzeń, zmniejszenia narzutu frameworka lub rozbicia long tasks w kodzie runtime. Grupowanie według stanu ładowania daje ten podział bez żadnej ręcznej instrumentacji.

W danych CoreDash z monitorowanych stron rozkład interakcji INP według stanu ładowania wynosi około: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. Większość interakcji zachodzi po pełnym załadowaniu strony, ale najgorsze wyniki INP zdecydowanie kumulują się we wczesnych stanach.

Zrzut ekranu

Dlaczego stan ładowania ma znaczenie dla INP

Metryka Interaction to Next Paint mierzy pełne opóźnienie interakcji użytkownika: opóźnienie wejściowe (input delay), czas przetwarzania funkcji obsługi zdarzeń oraz opóźnienie prezentacji do następnej wyrenderowanej klatki. Z tych trzech komponentów to opóźnienie wejściowe jest najbardziej zależne od tego, co przeglądarka robi w momencie kliknięcia lub dotknięcia ekranu przez użytkownika.

Podczas wczesnego ładowania strony main thread jest maksymalnie obciążony. Przeglądarka przetwarza HTML, wykonuje synchroniczne skrypty, buduje CSSOM, uruchamia zasoby blokujące parser i wywołuje cykle renderowania jeden po drugim. Każde long task na main thread to okno czasowe, w którym interakcja użytkownika trafia do kolejki i czeka. To oczekiwanie to właśnie opóźnienie wejściowe (input delay) – główny powód słabego INP podczas ładowania strony.

Interakcje, które następują po tym, jak document.readyState osiągnie stan complete, trafiają na mniej obciążony main thread. Przeglądarka zakończyła ładowanie. Jeśli INP na tym etapie jest nadal słaby, przyczyną nie jest przeciążenie podczas ładowania. Przyczyną jest JavaScript uruchamiany przez stronę w odpowiedzi na działania użytkownika: przeładowane funkcje obsługi zdarzeń, ponowne renderowanie frameworka, layout thrashing wywoływany przez skrypty lub nieoptymalny kod firm trzecich wykonywany synchronicznie podczas interakcji.

Stan ładowania to najszybszy filtr pozwalający rozdzielić te dwie główne przyczyny.

Stany ładowania

loading

Strona nie skończyła jeszcze przetwarzać dokumentu HTML. Main thread wykonuje synchroniczne skrypty, pobiera zasoby blokujące parser i buduje początkowy DOM. To najbardziej wrogie środowisko dla interakcji z użytkownikiem. Opóźnienie wejściowe jest wtedy największe, ponieważ każde long task bezpośrednio blokuje przeglądarkę przed przetworzeniem kliknięcia lub dotknięcia. Użytkownicy wchodzący w interakcję w tym oknie to zazwyczaj najbardziej niecierpliwi odwiedzający lub osoby z szybkim łączem, które widzą treść przed zakończeniem ładowania strony. Ich wyniki INP będą najgorszymi, jakie zarejestrujesz. Jeśli znaczna część Twoich słabych zdarzeń INP ma stan loading, przenieś niekrytyczne skrypty do defer lub async i wyeliminuj zasoby blokujące parser powyżej linii zgięcia (above the fold).

dom-interactive

document.readyState osiąga stan interactive, gdy HTML jest w pełni przetworzony, a DOM zbudowany, ale zasoby podrzędne, takie jak obrazy, arkusze stylów i odroczone skrypty, wciąż się ładują. W tym momencie zaczynają się wykonywać odroczone skrypty, co oznacza, że main thread może być wciąż mocno zajęty. Często w tym miejscu rozpoczyna się hydratacja frameworka. To niebezpieczne okno czasowe: strona wygląda na gotową, ale main thread nadal pracuje. Opóźnienie wejściowe pozostaje podwyższone. Jeśli słaby INP koncentruje się tutaj, rozwiązanie jest takie samo jak dla stanu loading: zmniejsz ilość pracy synchronicznej wykonywanej natychmiast po zakończeniu przetwarzania DOM.

dom-content-loaded

Zdarzenie DOMContentLoaded zostało wywołane. DOM jest kompletny, a odroczone skrypty zostały wykonane. Większość frameworków JavaScript kończy do tego momentu swoją początkową fazę hydratacji. Obciążenie main thread spada, a interakcje zaczynają otrzymywać szybsze odpowiedzi. Wyniki INP w tym stanie są zazwyczaj lepsze niż w dwóch poprzednich, ale nadal podwyższone w porównaniu do complete. Jeśli widzisz tu kumulację słabych interakcji, sprawdź, co robi Twój framework lub skrypty aplikacji w funkcjach obsługi DOMContentLoaded oraz czy proces hydratacji może być podzielony lub yielded, aby umożliwić przetwarzanie danych wejściowych między zadaniami.

complete

document.readyState osiąga stan complete, gdy wszystkie zasoby, w tym obrazy, czcionki i ramki iframe firm trzecich, zostaną załadowane. To stabilny stan, w którym strona działa przez resztę sesji. Słaby INP w tym stanie to czysty problem w runtime. Strona zakończyła ładowanie. Jeśli main thread nadal blokuje interakcje, przyczyna leży w wykonywaniu JavaScript podczas interakcji: funkcje obsługi zdarzeń wykonują zbyt dużo pracy synchronicznej, aktualizacje frameworka wywołują kosztowne ponowne obliczenia układu (layout) lub skrypty firm trzecich nieustannie uruchamiają long tasks. Rozwiązanie nie polega na odraczaniu. Chodzi o zmniejszenie kosztu działań, które następują po kliknięciu przez użytkownika.

Procedura debugowania

Krok 1: Filtruj według stanu ładowania w CoreDash. Otwórz tabelę podziału INP i pogrupuj dane według Load State. Zidentyfikuj, który stan ma największy udział słabych interakcji (powyżej 200 ms). To natychmiast pokaże Ci, czy masz do czynienia z problemem ładowania, czy runtime.

Krok 2: Powiąż dane z adresem URL i urządzeniem. Połącz wymiar Load State z wymiarem URL, aby sprawdzić, które konkretnie strony generują słabe interakcje we wczesnych stanach ładowania. Urządzenia mobilne są bardziej podatne na problemy podczas ładowania, ponieważ wolniejsze procesory wydłużają każde long task.

Krok 3: Dopasuj rozwiązanie do stanu. Dla stanów loading i dom-interactive przeprowadź audyt strategii ładowania skryptów, korzystając z przewodnika Optimize INP. Przenieś skrypty do defer, wyeliminuj zasoby render blocking i użyj scheduler.yield() do rozbicia długich zadań inicjalizacyjnych. Dla stanu complete sprofiluj funkcje obsługi zdarzeń w Chrome DevTools i zmniejsz ilość pracy synchronicznej wywoływanej przy każdej interakcji.

Inżynierska zasada kciuka

Jeśli ponad 30% słabych interakcji INP ma tag loading lub dom-interactive, Twój problem z INP wynika z ładowania strony, a największą poprawę przyniesie odroczenie JavaScript. Jeśli ponad 60% słabych interakcji ma tag complete, Twój problem z INP dotyczy runtime i musisz zoptymalizować koszt funkcji obsługi zdarzeń, a nie kolejność ładowania skryptów. Wymiar Load State (INP) pozwala to ocenić w jednym widoku tabeli, bez potrzeby sesji laboratoryjnej czy niestandardowej instrumentacji.