Problemy z INP wyjaśnione: przyczyny wolnych interakcji i jak je naprawić
Interaction to Next Paint (INP) to Core Web Vital mierzący, jak szybko strona reaguje na kliknięcia, dotknięcia i naciśnięcia klawiszy. INP powyżej 200 ms sprawia wrażenie ociężałości; powyżej 500 ms — awarii.
Niemal każdy zły INP sprowadza się do jednej z kilku przyczyn źródłowych. Każdy przewodnik poniżej omawia jedną przyczynę: jak ją rozpoznać, dlaczego występuje i jak ją naprawić — z kodem.
Przyczyny źródłowe
Długo działająca obsługa zdarzenia blokuje główny wątek i opóźnia kolejne renderowanie. Jak znaleźć ciężkie obsługi i podzielić je za pomocą scheduler.yield() lub Web Workers.
Layout thrashing: powtarzające się reflowy w jednej klatce i jak je zatrzymaćNaprzemienne odczyty i zapisy DOM zmuszają przeglądarkę do wielokrotnego przeliczania układu w jednej klatce. Jak grupować odczyty i zapisy, aby naprawić INP.
Wymuszony synchroniczny layout: odczyt geometrii po zapisie do DOMOdczyt offsetWidth lub getBoundingClientRect tuż po zmianie DOM zmusza przeglądarkę do przeliczenia układu w Twoim zadaniu JS. Jak to wykryć i naprawić.
Główny wątek zablokowany: wysoki input delay, zanim obsługa w ogóle zadziałaGdy główny wątek jest zajęty inną długą pracą, kliknięcia czekają w kolejce, zanim obsługa się uruchomi. Jak znaleźć i podzielić blokujące zadanie, aby naprawić input delay INP.
Skrypty zewnętrzne blokujące interakcje: diagnozowanie i ograniczanieAnalityka, reklamy i widżety czatu uruchamiają długie zadania na Twoim głównym wątku i niszczą INP. Jak przypisać długie zadania podmiotom zewnętrznym i ograniczyć je za pomocą async, defer lub workera.
Kaskada ponownych renderów React: gdy jedno kliknięcie renderuje całe drzewoAktualizacja stanu wysoko w drzewie React renderuje ponownie setki komponentów przy każdym kliknięciu. Jak znaleźć kaskady renderów i naprawić je za pomocą memo, useCallback i useTransition.