Wymiar Core/Dash: Stan ładowania (INP)

Wymiar: Stan ładowania INP (inpls)

Wymiar Stan ładowania (INP) rejestruje stan gotowości dokumentu (document ready state) w dokładnym momencie przechwycenia interakcji użytkownika. Każde zdarzenie INP w raporcie Chrome User Experience zawiera znacznik stanu ładowania: loading, dom-interactive, dom-content-loaded lub complete. CoreDash eksponuje ten znacznik jako wymiar, który można filtrować i grupować, dzięki czemu możesz odpowiedzieć na pytanie, na które nie odpowiadają surowe wyniki INP: kiedy w cyklu życia strony wystąpiła najgorsza interakcja?

To pytanie stanowi linię podziału między dwiema zupełnie różnymi poprawkami inżynieryjnymi. Problem z INP, który kumuluje się w fazie loading, wymaga strategii odraczania ładowania JavaScript. Problem z INP, który występuje w fazie complete, wymaga odchudzenia pracy procedur obsługi zdarzeń, zmniejszenia narzutu frameworka lub podzielenia długich zadań w kodzie uruchomieniowym. Grupowanie według stanu ładowania zapewnia ten podział bez jakiejkolwiek ręcznej instrumentacji.

W danych CoreDash z monitorowanych witryn, rozkład interakcji INP według stanu ładowania wynosi w przybliżeniu: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. Większość interakcji ma miejsce po pełnym załadowaniu strony, ale najgorsze wyniki INP w zdecydowanej większości grupują 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ścia (input delay), czas przetwarzania procedury obsługi zdarzeń oraz opóźnienie prezentacji (presentation delay) do następnej wyrenderowanej klatki. Z tych trzech elementów, opóźnienie wejścia jest tym, na który najbardziej bezpośredni wpływ ma to, co przeglądarka robi w momencie kliknięcia lub dotknięcia ekranu przez użytkownika.

Podczas wczesnego ładowania strony wątek główny jest maksymalnie obciążony. Przeglądarka parsuje HTML, wykonuje synchroniczne skrypty, buduje CSSOM, uruchamia zasoby blokujące parser i inicjuje cykle renderowania jeden po drugim. Każde długie zadanie (long task) w wątku głównym to okno, w którym interakcja użytkownika trafia do kolejki i czeka. To oczekiwanie to opóźnienie wejścia, które jest głównym powodem słabego wyniku INP podczas ładowania strony.

Interakcje, które pojawiają się po tym, jak document.readyState osiągnie complete, napotykają spokojniejszy wątek główny. Przeglądarka zakończyła ładowanie. Jeśli INP jest nadal słabe na tym etapie, przyczyną nie jest rywalizacja o zasoby podczas ładowania. Jest to JavaScript, który Twoja strona uruchamia w odpowiedzi na działania użytkownika: przeładowane procedury obsługi zdarzeń, cykle ponownego renderowania frameworka, thrashing układu wyzwalany przez skrypty lub niezooptymalizowany kod firm trzecich wykonujący się synchronicznie podczas interakcji.

Stan ładowania to najszybszy pojedynczy filtr pozwalający oddzielić od siebie te dwie podstawowe przyczyny.

Stany ładowania

loading

Strona nie skończyła jeszcze parsowania dokumentu HTML. Wątek główny wykonuje synchroniczne skrypty, pobiera zasoby blokujące parser i buduje początkowy model DOM. To najbardziej nieprzyjazne środowisko dla interakcji użytkownika. Opóźnienie wejścia jest najwyższe, ponieważ każde długie zadanie bezpośrednio blokuje przeglądarkę przed przetworzeniem kliknięcia lub dotknięcia. Użytkownicy, którzy podejmują interakcję w tym oknie, to zazwyczaj najbardziej niecierpliwi odwiedzający lub ci z szybkimi połączeniami, którzy docierają do widocznej zawartości przed zakończeniem ładowania strony. Ich wyniki INP będą najgorszymi, jakie zbierzesz. Jeśli znaczna część słabych zdarzeń INP ma stan loading, przenieś niekrytyczne skrypty do defer lub async i wyeliminuj zasoby blokujące parser widoczne na pierwszym ekranie (above the fold).

dom-interactive

document.readyState osiąga interactive, gdy dokument HTML jest w pełni sparsowany i zbudowany jest DOM, ale zasoby podrzędne, takie jak obrazy, arkusze stylów CSS i skrypty z atrybutem defer, wciąż się ładują. Odroczone skrypty zaczynają się wykonywać w tym momencie, co oznacza, że wątek główny nadal może być mocno obciążony. Często zaczyna się tu hydratacja frameworka. Jest to niebezpieczne okno, ponieważ strona wygląda na gotową dla użytkownika, ale wątek główny jest nadal zajęty. Opóźnienie wejścia pozostaje podwyższone. Jeśli zły wynik INP koncentruje się tutaj, rozwiązanie jest takie samo jak dla loading: zmniejsz ilość pracy synchronicznej, która jest uruchamiana natychmiast po zakończeniu parsowania DOM.

dom-content-loaded

Zdarzenie DOMContentLoaded zostało wywołane. DOM jest kompletny, a odroczone skrypty zostały wykonane. Większość frameworków JavaScript zakończyła w tym momencie początkowy proces hydratacji. Obciążenie wątku głównego spada, a interakcje zaczynają uzyskiwać szybsze odpowiedzi. Wyniki INP w tym stanie są zazwyczaj lepsze niż w dwóch wcześniejszych stanach, ale nadal podwyższone w porównaniu do complete. Jeśli zauważysz w tym miejscu nagromadzenie słabych interakcji, przyjrzyj się, co robią twoje skrypty frameworka lub aplikacji w procedurach obsługi DOMContentLoaded i sprawdź, czy proces hydratacji można podzielić na mniejsze fragmenty lub zastosować yielding, aby umożliwić przetwarzanie danych wejściowych między zadaniami.

complete

document.readyState osiąga complete, gdy wszystkie zasoby, w tym obrazy, czcionki i ramki iframe stron trzecich, zostaną załadowane. Jest to stan ustabilizowany, w którym strona działa przez resztę sesji. Słabe INP na tym etapie to czysty problem z czasem wykonywania (runtime). Strona jest w pełni załadowana. Jeśli wątek główny nadal blokuje interakcje, przyczyna leży w sposobie wykonywania JavaScriptu podczas interakcji: procedury obsługi zdarzeń wykonują zbyt dużo pracy synchronicznej, aktualizacje frameworka wyzwalają kosztowne ponowne przeliczanie układu lub skrypty firm trzecich nieustannie uruchamiają długie zadania. Poprawka nie polega na odraczaniu. Chodzi o zredukowanie kosztu operacji, które mają miejsce w momencie faktycznego kliknięcia przez użytkownika.

Przepływ pracy przy debugowaniu

Krok 1: Filtruj po stanie ładowania w CoreDash. Otwórz tabelę podziału INP i pogrupuj według stanu ładowania. Zidentyfikuj, który stan ma najwyższy odsetek słabych (powyżej 200 ms) interakcji. To od razu powie ci, czy masz do czynienia z problemem podczas ładowania, czy w czasie wykonywania kodu.

Krok 2: Skrzyżuj z adresem URL i urządzeniem. Połącz wymiar Stan ładowania z wymiarem URL, aby znaleźć konkretne strony, które generują słabe interakcje na wczesnych etapach ładowania. Urządzenia mobilne są nieproporcjonalnie mocno obciążone podczas ładowania, ponieważ wolniejsze procesory wydłużają każde długie zadanie.

Krok 3: Dopasuj poprawkę do stanu. W przypadku loading oraz dom-interactive przeprowadź audyt strategii ładowania skryptów, korzystając z poradnika optymalizacji INP. Przenieś skrypty do defer, wyeliminuj zasoby blokujące renderowanie i użyj scheduler.yield(), aby podzielić długie zadania inicjujące. W przypadku complete sprofiluj procedury obsługi zdarzeń w Chrome DevTools i zmniejsz synchroniczną pracę, którą wyzwalają podczas każdej interakcji.

Praktyczna zasada inżynieryjna

Jeśli ponad 30% twoich słabych interakcji INP jest oznaczonych jako loading lub dom-interactive, twój problem z INP dotyczy ładowania strony, a odroczenie JavaScriptu przyniesie największą poprawę. Jeśli ponad 60% słabych interakcji jest oznaczonych jako complete, twój problem z INP pojawia się w czasie działania aplikacji (runtime) i musisz zoptymalizować koszt procedur obsługi zdarzeń, a nie kolejność ładowania skryptów. Stan ładowania (INP) pozwala podjąć tę decyzję na podstawie jednego widoku tabeli, bez konieczności prowadzenia testów w środowisku laboratoryjnym ani stosowania niestandardowej instrumentacji.